具体的に、何を測定する？ Throughput? Connection latency? select() execution time? Number of instructions to process an incoming TCP packet?
Idea 1: Several years ago, the issue of "wake one" versus "thundering herd" on socket accept() was a concern in TCP performance. Has this issue been resolved? Checking the performance of *recent* OSes would be interesting: what happens when ten processes are waiting on an incoming TCP connection? 100? 1000?
Look into the Linux kernel code to see how this was resolved. Read https://usenix.org/events/usenix2000/freenix/full_papers/molloy/molloy_html/index.html for more information on the problem.
Idea 2: Investigate how much "interrupt coalescing" actually reduces the CPU processing necessary for incoming TCP traffic. Do back-to-back packets actually use less CPU than packets that are spaced out a little bit?
Measuring this one well will be a *hard* problem, but it could be a good problem for a team.
まだディテールはたりないよ！
返信削除具体的に、何を測定する？ Throughput? Connection latency? select() execution time? Number of instructions to process an incoming TCP packet?
Idea 1:
Several years ago, the issue of "wake one" versus "thundering herd" on socket accept() was a concern in TCP performance. Has this issue been resolved? Checking the performance of *recent* OSes would be interesting: what happens when ten processes are waiting on an incoming TCP connection? 100? 1000?
Look into the Linux kernel code to see how this was resolved. Read
https://usenix.org/events/usenix2000/freenix/full_papers/molloy/molloy_html/index.html
for more information on the problem.
Idea 2:
Investigate how much "interrupt coalescing" actually reduces the CPU processing necessary for incoming TCP traffic. Do back-to-back packets actually use less CPU than packets that are spaced out a little bit?
Measuring this one well will be a *hard* problem, but it could be a good problem for a team.
一番知りたいこと：何を測定する？どうやって測定する？何を勉強になる？