Tag: benchmark

Tun­ing guide in the wiki

In the light of the recent bench­mark dis­cus­sion, a vol­un­teer import­ed the tun­ing man-page into the wiki. Some com­ments at some places for pos­si­ble improve­ments are already made. Please go over there, have a look, and par­tic­i­pate please (testing/verification/discussion/improvements/…).

As always, feel free to reg­is­ter with First­name­Last­name and tell a FreeB­SD com­mit­ter to add you to the con­trib­u­tors group for write access (you also get the ben­e­fit to be able to reg­is­ter for an email noti­fi­ca­tion for spe­cif­ic pages).

Share/Save

How big are the buffers in FreeB­SD drivers?

Today I have read an inter­est­ing inves­ti­ga­tion and prob­lem analy­sis from Jim Get­tys.

It is a set of arti­cles he wrote over sev­er­al months and is not fin­ished writ­ing as of this writ­ing (if you are deeply inter­est­ed in it go and read them, the most inter­est­ing ones are from Decem­ber and Jan­u­ary and the com­ments to the arti­cles are also con­tribut­ing to the big pic­ture). Basi­cal­ly he is telling that a lot of net­work prob­lems users at home (with ADSL/cable or WLAN) expe­ri­ence  are because buffers in the net­work hard­ware or in oper­at­ing sys­tems are too big. He also pro­pos­es workarounds until this prob­lem is attacked by OS ven­dors and equip­ment manufacturers.

Basi­cal­ly he is telling the net­work con­ges­tion algo­rithms can not do their work good, because the net­work buffers which are too big come into the way of their work (not report­ing pack­et loss time­ly enough respec­tive­ly try to not lose pack­ets in sit­u­a­tions where pack­et loss would be bet­ter because it would trig­ger action in the con­ges­tion algorithms).

He inves­ti­gat­ed the behav­ior of Lin­ux, OS X and Win­dows (the sys­tem he had avail­able). I want­ed to have a quick look at the sit­u­a­tion in FreeB­SD regard­ing this, but it seems at least with my net­work card I am not able to see/find the cor­re­spond­ing size of the buffers in dri­vers in 30 seconds.

I think it would be very good if this issue is inves­ti­gat­ed in FreeB­SD, and apart from maybe tak­ing some action in the source also write some sec­tion for the hand­book which explains the issue (one prob­lem here is, that there are sit­u­a­tions where you want/need to have such big buffers and as such we can not just down­size them) and how to bench­mark and tune this.

Unfor­tu­nate­ly I even have too much on my plate to even fur­ther look into this. 🙁 I hope one of the net­work peo­ple in FreeB­SD is pick­ing up the ball and starts playing.

Share/Save

Are USB mem­o­ry sticks real­ly that bad?

Last week my ZFS cache device – an USB mem­o­ry stick – showed xxxM write errors. I got this stick for free as a pro­mo, so I do not expect it to be of high qual­i­ty (or wear-leveling or sim­i­lar life-saving things). The stick sur­vived about 9 months, dur­ing which it pro­vid­ed a nice speed-up for the access to the cor­re­spond­ing ZFS stor­age pool. I replaced it by anoth­er stick which I got for free as a pro­mo. This new stick sur­vived… one long week­end. It has now 8xxM write errors and the USB sub­sys­tem is not able to speak to it any­more. 30 min­utes ago I issued an “usb­con­fig reset” to this device, which is still not fin­ished. This leads me to the ques­tion if such sticks are real­ly that bad, or if some prob­lem crept into the USB subsystem?

If this is a prob­lem with the mem­o­ry stick itself, I should be able to repro­duce such a prob­lem on a dif­fer­ent machine with a dif­fer­ent OS. I could test this with FreeB­SD 8.1, Solaris 10u9, or Win­dows XP. What I need is an auto­mat­ed test. This rules out the Win­dows XP machine for me, I do not want to spend time to search a suit­able test which is avail­able for free and allows to be run in an auto­mat­ed way. For FreeB­SD and Solaris it prob­a­bly comes down to use some disk‑I/O bench­mark (I think there are enough to chose from in the FreeB­SD Ports Col­lec­tion) and run it in a shell-loop.

Share/Save