I2P 개발자 회의 - 2006년 3월 7일

15:08 <jrandom> 0) 안녕 15:08 <jrandom> 1) 네트워크 상태 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) 안녕 15:08 * jrandom 손을 흔든다 15:08 <jrandom> 주간 상태 노트를 http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 에 올려뒀어 15:09 * jrandom 그 엄청 긴 노트 읽어보라고 여러분에게 몇 시간 줄게 15:10 * Complication 아직 눈치 못 챘던 척 ;) 15:11 <+Complication> 안녕하세요 :) 15:11 <+susi23> 안녕하세요 :) 15:12 <jrandom> 그럼, 1) 네트워크 상태로 들어가보자 15:12 <jrandom> 메일에 지금 무슨 일이 벌어지는지에 대한 내 전반적인 관점을 적어놨어. 너희가 보고 있는 것들과 어떻게 맞아? 15:13 <+Complication> 스로틀링 수정으로 안정성은 올라간 것 같은데, 대역폭은 꽤 눌렸어 15:13 <+Complication> 잠깐만, 그래프 찾아볼게 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> 높은 구간은 최신 이전 버전, 낮은 구간은 최신에서 나와 15:15 <+Complication> 제한 설정은 같고, 아마 (더 엄격한) 최신 버전에선 좀 더 느슨하게 잡았을지도 15:16 <+Complication> 그래도 전송은 되니까 큰 문제는 아냐 15:16 <jrandom> 좋아, 실제 대역폭 한계에 가까워질수록 대역폭 사용이 줄어드는 게 적절해 15:17 <+Complication> 대부분, '지속 대역폭' 한도에 이르기 전에 반등하는 것 같아 15:17 <+Complication> 버스트 한도는 전혀 건드리지도 않고 15:18 <+Complication> (그 자체로는 합리적인데 - 걱정되는 건 지속 한도 전에 반등한다는 점이야) 15:19 <bar> 나도 Complication이 보는 거랑 거의 같아. 총 대역폭 사용량이 최대 설정의 50%밖에 안 돼. 0.6.1.11 이전엔 대략 80%였어 15:19 <jrandom> 제한 속도가 200kbps고, 버스트가 300kbps야? 15:20 <jrandom> (버스트에서 얼마나 오래 머물렀는지 궁금해서) 15:20 <jrandom> 어쨌든 대역폭 사용량을 줄이는 게 최근 변경의 목표 중 하나야 15:21 <+Complication> 지속 ~225, 버스트 ~325 15:21 <+Complication> 잠깐, 내가 그럴 수도... 15:22 <+Complication> 내가 *해석을* 잘못한 거야? 15:23 <+Complication> 잊어줘, 내가 바보였어... 계산을 잘못했네, 그렇게까지 나쁘진 않아 :O 15:23 <jrandom> 데이터가 부족해 :) 문제의 징후일 수도 있지만, 네가 지금까지 설명한 걸로는 의도대로 동작하는 듯해 15:23 <+Complication> 좀 보수적인 편이긴 한데, 내가 생각했던 만큼 나쁘진 않아 15:24 <+Complication> Router Console(제한과 같은 단위를 사용해 측정함)에 따르면, 아웃바운드 전체 평균은 지속 한도의 2/3, 버스트 한도의 1/2이야 15:25 <+Complication> 하지만 인바운드 전체 평균은 지속 한도의 1/3을 약간 상회하고, 버스트 한도의 1/4 정도에 불과해 15:26 <+Complication> 예를 들어, 지속 한도가 30이고 버스트 한도가 40이라고 하면, 아웃바운드는 20, 인바운드는 10을 조금 넘는 수준이야(주로 부하 부족 때문) 15:26 <jrandom> 좋아 15:26 <+Complication> 하지만 내가 그래프를 잘못 해석했어, Kb/KB 문제 때문에 :O 15:27 * Complication 역사에서 그래프를 지워버린다 15:28 <jrandom> 그래도 눈썰미 좋네, 뭔가 이상해 보이면 꼭 알려줘 15:28 <jrandom> 좋아, 1) 네트워크 상태에 대해 다른 거 있어? 15:28 <jrandom> 없으면, 2) ???로 살짝 넘어가자 15:28 <jrandom> 다른 얘기할 거 있어? 15:30 <+Complication> 음, jbigi 테스트가 좀 있었는데, 어떤 사람은 Linux용 64비트 버전이 꽤 느리다는 결과를 얻었다고 해 15:31 <+Complication> 순수 Java보다도 느리게 나왔대, 측정 오류인지 아닌지는 잘 모르겠어 :O 15:32 <+Complication> 나는 재현할 수 없었어 15:32 <jrandom> 응, 그 플랫폼에서 어떤 .so를 쓰고 있었는지 나도 정확히는 모르겠어 15:32 <+Complication> 내 쪽에선 순수 Java보다 대략 두 배 빨랐어 15:32 <+dust> syndie에서 추가 메시지 포맷으로 HTML을 쓰는 실험이 이제 동작하기 시작했어. 내 로컬 'sucker'가 이제 웹 페이지(이미지 포함)를 가져와서 syndie 게시물로 저장할 수 있어 15:33 <jrandom> 아 멋지다 dust 15:33 <+dust> 근데 CSS는 없어 15:33 <+Complication> 근데 32비트에선 순수 Java보다 *훨씬* 빠르다고들 하더라(10배 정도 같은) 15:35 <bar> 흠.. Complication, 지금 amd64 .so가 32비트 시스템용만이고, 그는 64비트 OS에서 테스트한 건 아닐까? 15:36 <+Complication> bar: 그럴 수도, 나도 64비트 OS에서 테스트했거든 :O 15:36 <jrandom> 내 기억이 맞다면 amd64는 pure64 debian에서 동작하도록 빌드됐어 15:37 <+Complication> 어쨌든, 더 최신 gmp를 들여오면 도움이 될 거란 제안이 있었어 15:37 <bar> 그냥 찍어본 거야, 이런 건 전문가가 아니라서 15:37 <jrandom> 음, 우리는 4.1.4를 써 15:37 <+Complication> 특히 곧 버전 점프를 한 뒤에는 더 그럴 거라고 15:38 <+Complication> 나는 gmp 전문가가 아니라서 뭐라 말하긴 어려워 15:38 <jrandom> (그리고 gmp의 다가올 최적화가 크게 개선되진 않을 거야) 15:38 <+Complication> '그럴 수도'라는 말 말곤 15:38 <jrandom> 개선은 아키텍처별 빌드에서 나와 15:40 <+Complication> 그들의 테스트를 보고 나서 내 쪽에서도 테스트해봤는데, 64비트 Mandriva의 64비트 Sempron에서 64비트 athlon lib을 썼더니... 순수 Java보다 약간만 더 빠른 것처럼 보였어 15:40 <+Complication> (아, 64비트 VM도) 15:41 <+Complication> ('약간'이 두 배 정도라는 뜻) 15:41 <jrandom> 흠, 오케이 15:42 <+Complication> 플랫폼 조합을 더 테스트해보고, 전달할 만한 게 있으면 알려줄게 15:43 <jrandom> 좋아, 고마워 15:43 <jrandom> 좋아, 회의에서 더 얘기할 거 있어? 15:46 <jrandom> 없다면... 15:46 * jrandom 마무리한다 15:47 * jrandom *baf*s 회의를 종료한다