I2P 개발자 회의 - 2006년 5월 16일

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) 안녕하세요 <cervantes> 1) jrandom은 여기 없어요 <cervantes> 2) ??? <cervantes> 0) 안녕하세요 <cervantes> 안녕하세요 <cervantes> 1)로 넘어갈게요 <cervantes> jrandom은 오늘은 없고, 내일 상태 업데이트를 해 줄 거예요 <cervantes> 2) ??? <cervantes> 회의에 더 추가할 내용 있는 분 계신가요? <bar> 질문이 있어요 <cervantes> 그렇다면... * cervantes 몸을 풀기 시작한다 * cervantes 몸풀기를 멈춘다 <Complication> 아하, 질문이군요... <bar> cvs에 있는 PRNG(의사난수 생성기) 수정이 전반적인 성능을 향상시키나요, 아니면 다른 것과 관련이 있나요? <cervantes> 일반적으로 어떤 결과가 있을지는 확실치 않아요 <Complication> 전체 영향에 대해 제가 아는 바는 없지만, 적어도 제가 아는 두 가지 동작에는 관련이 있어요: <cervantes> 다만 i2ptunnel의 한 증상을 구체적으로 고쳐요 * cervantes가 complication이 풀어 설명하도록 놔둔다 <Complication> tunnel 길이 무작위화와 IRC 서버 선택(좀 더 일반적으로는, I2PTunnel 목적지 목록에서의 무작위 선택) <Complication> tunnel 길이 무작위화는 전체 네트워크 건강도에 상당한 영향을 줄 가능성이 커요. tunnel 길이에 타협할 수 있도록 허용된 클라이언트들이 실제로 그렇게 하게 해주거든요 <Complication> 그래서 숨죽이며 2-hop tunnel만 만드는 게 아니라, 1-hop tunnel도 시도하게 되죠 <Complication> (상황이 어려울 때는 1-hop이 훨씬 만들기 쉽거든요) <cervantes> 또, 배포가 되면 IRC 연결성도 개선될 수 있어요. 기본적으로 freshcoffee는 목록에서 두 번째였기 때문에 클라이언트 연결을 전혀 받지 못했어요 — 그래서 다음 릴리스에서는 부하가 두 서버에 고르게 분산될 거예요 <bar> 그러면 그 버그 때문에 가능한 경우 사람들이 항상 더 긴 tunnel 길이를 선택하게 된 건가요? <Complication> 제 이해로는, 작은 정수에 대한 모든 무작위화(예: 0 또는 1 선택)가 영향을 받았어요 <Complication> 큰 정수에 대한 무작위화(예: 0부터 100 사이의 정수 선택)는 영향이 덜했던 것 같아요 <Complication> 관심 있으시면, jranom이 돌아오면 자세한 건 그에게 물어보세요 <Complication> 제가 세부를 잘못 이해했을 수도 있어요. <bar> 알겠어요, 감사합니다. 잘 잡아내셨네요 <Complication> 음, cervantes가 여기 와서 과부하가 하나도 안 온다고 투덜대기 시작했거든요 ;P <cervantes> 저도 그렇게 이해했어요 <cervantes> 보세요...투덜대지 않으면 인생에서 아무것도 못 얻어요 :) <cervantes> 회의에 대해 다른 질문이나 주제 있으신가요? <fox> <duck> 네 <Pi> 일반적인 네트워크 건강도에 대한 질문: i2p 버전 측면에서 점점 더 많은 클라이언트가 뒤처지는 걸 봐요(아직도 0.6.1.11을 쓰는 2명 등). 이런 클라이언트들 때문에 코어 변경의 효과를 모니터링하기가 점점 더 어려워지지 않을까요? (업데이트하려는 사람이 "더 적어" 보이니까요) <fox> * duck이 위 내용을 반복 * w423412323이 그와 관련된 주제로 바꾸자고 제안하네요. ;) <fox> <duck> 궁금한 게 있어요. cvs 메일링 리스트에서 좀 특이한 튜닝 커밋들을 봤어요. 그건 더 많은 실험인가요? 관찰에 기반한 건가요? 성급한 건가요? <Complication> Pi: 숫자가 많지 않은 한, 큰 차이는 없을 거예요 <Pi> 제 netdb 기준으로 지금 300개 클라이언트 중 70개가 0.6.1.18이 아닌 버전을 쓰고 있어요 <Complication> 숫자와 용량(capasity)의 게임이에요 — 대부분의 router나, 아니면 특히 고용량 router들이 적절히 업데이트되어 있으면, I2P를 설치해놓고 잊어버린 몇몇 사람들은 크게 문제 되지 않죠 :) <cervantes> Pi: 오래된 router들이 제대로 동작하지 않으면 네트워크가 _적응해서_ 그들을 통해 라우팅되는 트래픽을 줄이도록 해야 해요 <cervantes> *'being routed'라고 정정 <cervantes> Complication: duck의 질문 봤어요? <Pi> 그리고 얼마 전에 i2p-console에 나타난 통계 하나에 대한 질문: handle backlog(처리 대기 건수)는 무슨 뜻이죠? <Complication> duck: tunnel 스로틀 조정 말하시는 건가요? 본질적으로 새로움을 가져오는 건 아니지만, 꽤 잘 테스트된 튜닝이에요(예: 아마 여러분을 물지는 않을 거예요, 아니 byte하지는 않을 겁니다) <Complication> 다만, 제가 생각한 매개변수 범위를 완전히 벗어난 매우 특이한 설정을 돌린다면, 조금은 byte할 수도 있어요 <fox> <duck> Complication: '3' 대신 '2'로 바꾼 것들이 정말 그렇게 큰 차이를 만들었나요? <fox> <duck> 그런데 무작위 관련 문제가 꽤 큰 악당이었을 수도 있겠네요 <fox> <duck> (물론 그게 네트워크 건강도에 미친 상대적 영향은 그 문제가 언제 도입됐는지에 달려요) <cervantes> Pi: handle backlog는 보류 중인 인바운드 tunnel 참가 요청 수예요(변경 로그에서 인용) <Complication> 무작위 nextInteger() 문제와, tunnel 길이 무작위화에 대한 영향 말씀이라면, 꽤 큰 효과가 있었을 거라고 느껴요 <Complication> 1-hop과 2-hop tunnel을 구축하는 비용 차이가 꽤 크거든요 <Pi> 고마워요, cervantes :) <fox> <duck> 그게 언제 도입됐죠? <Complication> duck: Fortuna 생성기로 일부 전환하면서, 아니면 그 내부 수정 중에 들어온 걸로 생각해요 <fox> <duck> 알겠어요; 의견 주셔서 정말 감사합니다 <Complication> 좀 더 자세한 건 cvsweb을 확인해볼게요... <cervantes> Pi: 지금은 큐가 가득 차면 인바운드 tunnel 요청을 드롭하는 코드가 들어가 있는 걸로 알아요(CPU 부하를 줄이기 위해) <Complication> Pi: 네, 그건 "다른 사람의 tunnel에 또 참여할 만큼 용량이 충분한가?"를 결정하는 데 쓰이는 또 다른 매개변수의 가시적 지표일 거예요 <cervantes> duck: 저는 그 수정이 들어간 이후 router 동작이 크게 달라진 걸 확실히 체감하고 있어요. — 좋기만 한 건 아니라고 해야겠네요 :) <Complication> 큰 handle backlog == 혼잡, 다른 사람의 tunnel에 참여하려고 해봤자 소용없죠 <cervantes> 그저께 load average가 14였고 participating tunnel이 12,000개였어요 <Complication> handle backlog는 특히 고용량 router에서 중요해 보입니다(cervantes가 본 것과 관련) <Complication> 저용량 router들은 일반적으로 대역폭 이유로 tunnel 수락을 스로틀링하죠 <Complication> (정확히는 tunnel 테스트 시간 때문이기도 하고요) <Complication> (적어도, 그렇게 하려고는 해요) <cervantes> 와, 벌써 30분이나 했네요.... <Complication> 그러게요 :D <cervantes> 다른 안건 올리실 분 계신가요? <cervantes> 그렇다면... * cervantes 몸을 풀기 시작한다 * cervantes가 회의를 *baffs* 닫는다 <fox> <duck> 회의 챙겨줘서 고마워요 <cervantes> 하하 사실 아무도 말하기 전에 baf로 닫아버리려고 했는데.... bar가 그 계획을 망쳤네요 :)