Hi, Was wondering if there are any plans to update either the kernel structures and/or netstat to show more than 4GB of traffic stats. For example, on a 4.8-STABLE machine: $ netstat -bI sis0 Name Mtu Network Address Ipkts Ierrs Ibytes ... sis0 1500 <Link#2> <mac-addr-hidden> 8789598 0 4103727771 ... <non-relevant parts removed> This shows that sis0 has received around 3.9GB. Then, after transferring approximately 200MB: $ netstat -bI sis0 Name Mtu Network Address Ipkts Ierrs Ibytes ... sis0 1500 <Link#2> <mac-addr-hidden> 9245518 0 18874368 ... The Ibytes line has dropped from 3.9GB to 18MB. It should of course be 4.1GB. How much would need to change in either the kernel or netstat to make >4GB possible? Best regards - Andy
andy@evo6.org said:> How much would need to change in either the kernel or netstat to make > > 4GB possible?At the very least: - edit sys/net/if.h & change struct if_data entries to u_int64_t. - edit usr.bin/netstat/if.c intpr() & change variables to be u_int64_t and use %ull in printf strings - redo all the layouts in if.c to handle the wider fields - recompile everything in the entire system - kernel, world, all ports that might look at network interfaces or routing tables, etc - hope that the broken binary compatibility doesn't hurt too bad
I also didn't like the limitation and we had long discussions about 64 bit counters in Jan 2002. The problem is that there isn't really cheap way to do safe (atomic) updates of 64 bit numbers on SMP x86. The conclusion at time was mostly that counting in 64 bit on 32 bit arch was too expensive. I have a patch which increases the width and adds small api for safe updating of wide counters (for 4.5 or something). Other solution is to keep the type of kernel-updated counters and if needed (on 32 bit archs) have some aggregation counters which would be once in a while (e.g. 10 times a second) updated with some kernel thread. I also have proof-of-concept patch with this approach. As SMPng locking of network stack and drivers is taking place it seems some counters could be made u_int64 rather cheaply - the structures containing the counters should be locked for update anyway so the update can be achieved then by simple means even on 32bit arch. -- Michal Mertl mime@traveller.cz
> I've forgotten the orginaly discussion last year - just how expensive > is it again to do a locked 64bit update on x86? If it is less than say > 8x the time to do a 32bit increment, then we should probably just bite > the bullet and do it for the few counters where it makes sense (input > and output bytes and packets).The price for locked 64bit update was really high. I can't find my measurements from that time, but it was more on the scale of 100 times more expensive. -- Michal Mertl mime@traveller.cz