Minor tweaks from a one-day binge of performance analysis.
The only meaningful change was to insert a sched_yield() in the frisbee decompressor path. Apparently, the decompressor can run long enough to cause the incoming socket buffer to overflow. I was under the assumption that the decompressor would not run much longer than a single time slice (0.001 seconds, about 8 packets) before its priority would force it to be context switched. But it was running much longer than that! Forcing a periodic yield seems to have taken care of this. One other cause of retransmitted blocks that I saw was where the server was taking a long time to read data from a file (up to 0.25 seconds). This would stall the clients and force them to rerequest blocks (which they do after about 0.10 seconds). We can improve on this by splitting the file reading off to a seperate thread. Most other changes are related to the event logging code.
Showing
- os/frisbee.redux/GNUmakefile.in 1 addition, 1 deletionos/frisbee.redux/GNUmakefile.in
- os/frisbee.redux/client.c 24 additions, 8 deletionsos/frisbee.redux/client.c
- os/frisbee.redux/server.c 25 additions, 16 deletionsos/frisbee.redux/server.c
- os/frisbee.redux/trace.c 33 additions, 16 deletionsos/frisbee.redux/trace.c
- os/frisbee.redux/trace.h 6 additions, 5 deletionsos/frisbee.redux/trace.h
- os/imagezip/imageunzip.c 17 additions, 1 deletionos/imagezip/imageunzip.c
Loading
Please register or sign in to comment