Re: tcpbench udp support + libevent.
On 2011/02/17 19:37, Christiano F. Haesbaert wrote: So here is a better diff, plus the changes to the manpage and usage() which were lacking. When I get a ENOBUFS in UDP I simply return to event_dispatch(). Nice, it is a bit more consistent than netblast. With 1 byte UDP: Sent by tcpbench -u -B1 host: Elapsed:1000 Mbps: 0.626 Peak Mbps: 0.626 Rx PPS: 78274.000 Elapsed:2000 Mbps: 0.577 Peak Mbps: 0.626 Rx PPS: 72118.000 Elapsed:3000 Mbps: 0.628 Peak Mbps: 0.628 Rx PPS: 78516.000 Elapsed:4000 Mbps: 0.643 Peak Mbps: 0.643 Rx PPS: 80415.000 Elapsed:5000 Mbps: 0.615 Peak Mbps: 0.643 Rx PPS: 76821.000 Elapsed:6000 Mbps: 0.581 Peak Mbps: 0.643 Rx PPS: 72668.000 Elapsed:7000 Mbps: 0.639 Peak Mbps: 0.643 Rx PPS: 79897.000 Elapsed:8000 Mbps: 0.590 Peak Mbps: 0.643 Rx PPS: 73722.000 Elapsed:9056 Mbps: 0.604 Peak Mbps: 0.643 Rx PPS: 75557.000 Elapsed: 10056 Mbps: 0.483 Peak Mbps: 0.643 Rx PPS: 60432.000 Elapsed: 11056 Mbps: 0.624 Peak Mbps: 0.643 Rx PPS: 78059.000 Elapsed: 12056 Mbps: 0.627 Peak Mbps: 0.643 Rx PPS: 78360.000 Elapsed: 13056 Mbps: 0.607 Peak Mbps: 0.643 Rx PPS: 75828.000 Elapsed: 14056 Mbps: 0.637 Peak Mbps: 0.643 Rx PPS: 79679.000 Elapsed: 15056 Mbps: 0.621 Peak Mbps: 0.643 Rx PPS: 77680.000 Sent by netblast host 12345 1 30: Elapsed:1285 Mbps: 0.528 Peak Mbps: 0.528 Rx PPS: 65954.000 Elapsed:2285 Mbps: 0.730 Peak Mbps: 0.730 Rx PPS: 91231.000 Elapsed:3285 Mbps: 0.738 Peak Mbps: 0.738 Rx PPS: 92197.000 Elapsed:4285 Mbps: 0.639 Peak Mbps: 0.738 Rx PPS: 79835.000 Elapsed:5285 Mbps: 0.418 Peak Mbps: 0.738 Rx PPS: 52238.000 Elapsed:6303 Mbps: 0.339 Peak Mbps: 0.738 Rx PPS: 42413.000 Elapsed:7303 Mbps: 0.683 Peak Mbps: 0.738 Rx PPS: 85437.000 Elapsed:8303 Mbps: 0.677 Peak Mbps: 0.738 Rx PPS: 84674.000 Elapsed:9303 Mbps: 0.487 Peak Mbps: 0.738 Rx PPS: 60928.000 Elapsed: 10303 Mbps: 0.565 Peak Mbps: 0.738 Rx PPS: 70665.000 Elapsed: 11303 Mbps: 0.588 Peak Mbps: 0.738 Rx PPS: 73527.000 Elapsed: 12375 Mbps: 0.513 Peak Mbps: 0.738 Rx PPS: 64082.000 Elapsed: 13375 Mbps: 0.698 Peak Mbps: 0.738 Rx PPS: 87302.000 Elapsed: 14375 Mbps: 0.700 Peak Mbps: 0.738 Rx PPS: 87440.000 Elapsed: 15375 Mbps: 0.574 Peak Mbps: 0.738 Rx PPS: 71786.000 (tcpbench -u -s makes a nice receiver for netblast/netsend :-) -The default is 262144 bytes. +The default is 262144 bytes for TCP client/server and UDP server. In UDP client, +this may be used to specify the packet size on the test stream. New sentence should be on a new line (here and in a couple of other lines), e.g. +The default is 262144 bytes for TCP client/server and UDP server. +In UDP client, this may be used to specify the packet size on the test stream. Maybe I would say 'In UDP client mode, [...]' One documentation nit (not related to your changes), tcpbench [-v] [-u] [-B buf] [-k kvars] [-n connections] [-p port] [-r rate] [-S space] [-V rtable] hostname I think using rate here implies something about packet rate, but this is actually for reporting, I would prefer the word interval. +#define DEFAULT_UDP_PKT (1500 - 28) /* TODO don't hardcode this */ I think you'll have to do a route lookup to determine the MTU of the recipient to avoid hardcoding this.
.libs handling
At least jeremy@ and landry@ got confused about this, so I expect more people to ask. The algorithms for package updates are a bit complicated, to say the least. When you update a package with shared libraries, those can get split off into a separate package with a .lib name (which is well known). This package can be removed manually later, once a full upgrade has been done and nothing depends on it (it's not done automatically because user-compiled programs may depend on it... I intend to have a pkg_create -u mode (user) to be able to quickly register user programs so that we CAN remove them automatically). Anyways... In the meantime, those .libs* will participate in updates. In modern pkg_add, pkg_add -u will organize packages to update as updatesets: the smallest set of packages that need to be updated together because of interdependencies/conflicts. Guess what ? a .libs-foo-* will always get pulled in when you update foo, because those two packages belong to the same software and contain files that may conflict. That's why you'll see lines like .libs-foo-1.0 + foo-2.0 - foo-3.0 That's because pkg_add needs to know what's going on. What you're not going to see, though, is the creation of new .libs (unless you use -vvv). But that is necessary. That way, if you need to downgrade back from foo-2.0 to foo-1.0, pkg_add knows enough about it to be able to merge back .libs-foo-1.0 into foo-1.0 instead of complaining about a conflict and stopping. I should probably show the creation of new .libs? that might make things more simple to understand. What happened is that this algorithm evolved, it's one of those details I hadn't figured out yet when we embarked on correct safe updates...
Re: .libs handling
On 2011-02-19, Marc Espie es...@nerim.net wrote: At least jeremy@ and landry@ got confused about this, so I expect more people to ask. The algorithms for package updates are a bit complicated, to say the least. When you update a package with shared libraries, those can get split off into a separate package with a .lib name (which is well known). FWIW, I have this ugly python script that I wrote some years ago and use regularly: http://www.pastie.org/1583994 It shows all packages which are not required by any other package and lets you remove them recursively. It will also show .libs which are not required anymore. I use it after every pkg_add -ui and every once in a while to get rid of stuff I don't need anymore. It would perhaps be interesting to reimplement it in python using the OpenBSD::Pkg* libraries. Best regards, Jona -- Worse is better Richard P. Gabriel
Re: .libs handling
http://users.cis.fiu.edu/~lusec001/moin.cgi/Software/OBSD_Recursive_pkg_del Luis On Sat, Feb 19, 2011 at 7:03 PM, Jona Joachim j...@hcl-club.lu wrote: On 2011-02-19, Marc Espie es...@nerim.net wrote: At least jeremy@ and landry@ got confused about this, so I expect more people to ask. The algorithms for package updates are a bit complicated, to say the least. When you update a package with shared libraries, those can get split off into a separate package with a .lib name (which is well known). FWIW, I have this ugly python script that I wrote some years ago and use regularly: http://www.pastie.org/1583994 It shows all packages which are not required by any other package and lets you remove them recursively. It will also show .libs which are not required anymore. I use it after every pkg_add -ui and every once in a while to get rid of stuff I don't need anymore. It would perhaps be interesting to reimplement it in python using the OpenBSD::Pkg* libraries. Best regards, Jona -- Worse is better Richard P. Gabriel
