Ethernet statistics

HI,

Iam trying to collect all possible adapter wise
network statistics from my Linux box.

Iam aware of the details given by /proc/net/dev
, wanted to know if there are any more finer
grained stats available

Like the no of frames tranmistted with only
one / multiple collisions or the no of times
collision was detected late into transmission etc


thanks
arun

"arun" <(E-Mail Removed)> wrote news:bh2c8o$sg3h1$1@ID-
164188.news.uni-berlin.de:

> Like the no of frames tranmistted with only
> one / multiple collisions or the no of times
> collision was detected late into transmission etc

What do you mean with "on/multiple" and "detected late" ?

I think you can't get more detail than the collision number, because the
ethernet tehnology can only detect collision while a frame is sent and it
can't know who and how much network interface cards are implied :

- listen to the ethernet medium
- if the medium is free (no frame in progess)
-> send the frame
-> listen to the medium while the frame is sending
-> if at any time the signal is different than the frame in progress
-> this is collision => abort, wait an retry

So the collision detection is made at a signal level, not at a "logical"
level, and the nic can't know what make the collision.

The collision is possible because, when the nic listen for the media to be
free, another nic can do the same and so 2 nic can start to transmit a
frame at the same time (or with a very little delay because a frame take
time to reach others nic on the medium (light speed limit)).


Regards

Antoine EMERIT <(E-Mail Removed)> said:
>"arun" <(E-Mail Removed)> wrote news:bh2c8o$sg3h1$1@ID-
>164188.news.uni-berlin.de:
>
>> Like the no of frames tranmistted with only
>> one / multiple collisions or the no of times
>> collision was detected late into transmission etc
>
>What do you mean with "on/multiple" and "detected late" ?

I read that as the OP wanting to have separate counters for packets
that have been sent with one collision and packets that have encountered
multiple collisions before getting sent.

The "detected late" situation apparently is what some network traffic
analyzers show as "late collisions". Theoretically, these should not
happen at all, but in practice these happen every now and then (or at
least did happen with 10Base-2/hub-based 10Base-T networks).

When a network interface starts sending a packet, it sends a preamble of
certain length, which is the indicator "I want to reserve this channel".
Regular collisions happen during the duration of this preamble -- so, two
interfaces have started sending at that exactly same moment that their
preambles collide on the medium. A "late collision" is a collision that
happens when an interface starts sending when some other interface has
completed its preamble and is already sending data.

So, much as you already described, but just exmplaining the difference of
a regular and a late collision.

>The collision is possible because, when the nic listen for the media to be
>free, another nic can do the same and so 2 nic can start to transmit a
>frame at the same time (or with a very little delay because a frame take
>time to reach others nic on the medium (light speed limit)).

.... actually the speed of signal on an Ethernet cable is much slower than
speed of light -- the capacitance and inductance of the cable slow down
the signal rather significantly. It's too long since I did the theory on
this topic (and I don't need the info in my field of work) that I could
calulate the actual speed, but the difference is huge.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

"arun" <(E-Mail Removed)> said:
>"Juha Laiho" <(E-Mail Removed)> wrote in message
>news:bh2n2e$d5q$(E-Mail Removed)-int...
>
>> I read that as the OP wanting to have separate counters for packets
>> that have been sent with one collision and packets that have encountered
>> multiple collisions before getting sent.
>
>> The "detected late" situation apparently is what some network traffic
>> analyzers show as "late collisions". Theoretically, these should not
>> happen at all, but in practice these happen every now and then (or at
>> least did happen with 10Base-2/hub-based 10Base-T networks).
>
>Thats just what i wanted to know - is there any way i can get hold of
>these stats in Linux ?

Not that I know of. The only place where I've seen "late collisions"
reported was a Fluke LAN analyzer -- so I can only guess that regular
network adapters do not maintain separate counters for these, but just
provide a summed counter about number of collisions detected overall.

Of course, my hands-on development experience with NICs is limited, and
outdated -- it might well be that some of the current NICs provide better
diagnostics (as processing power is plentiful and memory cheap).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

"Juha Laiho" <(E-Mail Removed)> wrote in message
news:bh8pg9$rlm$(E-Mail Removed)-int...
> "arun" <(E-Mail Removed)> said:
> >"Juha Laiho" <(E-Mail Removed)> wrote in message
> >news:bh2n2e$d5q$(E-Mail Removed)-int...
> >
> >Thats just what i wanted to know - is there any way i can get hold of
> >these stats in Linux ?
>
> Not that I know of. The only place where I've seen "late collisions"
> reported was a Fluke LAN analyzer -- so I can only guess that regular
> network adapters do not maintain separate counters for these, but just
> provide a summed counter about number of collisions detected overall.

This is something I have been coming up against in Linux these days
when I start to dig deep. Other commercial plats like sun and M$
supports more detailed interfaces to get almost any of the info you
want.(sun is best) However Linux is still at times somewhat behind
in this respect.

But of-course I'm limited to what the os tells me in those cases
whereas in Linux I can check the code and verify if the code is giving the
same data as the man page claims or find some back doors if possible.
But back doors / adding my own module / patches etc is not at all
acceptable from an enterprise perspective. Nobody would allow a new
module let alone a patch in their production servers. That kinda cool
things can be done only on our personal machines

I just hope Linux matures fast enough with regards to the manageability
(there would be other such aspects I guess, like volume management
and stuff I hear people talkin abt) and enterprise aspects fast enough

thanks
arun.


ps: waiting for 2.6 to completely shift daily stuff to Linux - cheers to the
developers

"Juha Laiho" <(E-Mail Removed)> wrote in message
news:bh8pg9$rlm$(E-Mail Removed)-int...
> "arun" <(E-Mail Removed)> said:
> >"Juha Laiho" <(E-Mail Removed)> wrote in message
> >news:bh2n2e$d5q$(E-Mail Removed)-int...
> >

> >Thats just what i wanted to know - is there any way i can get hold of
> >these stats in Linux ?
>
> Not that I know of. The only place where I've seen "late collisions"
> reported was a Fluke LAN analyzer -- so I can only guess that regular
> network adapters do not maintain separate counters for these, but just
> provide a summed counter about number of collisions detected overall.

when i tried googling for some driver code i see many of them maintain
counters for info like RX alignment errors and stuff. Only i dont know
what ioctl gets them for me (I didnt want to study the full code - maybe
i should now).

The few generic ioctls that i know of use to talk with net drivers are
SIOCETHTOOL SIOCMIIPHY & SIOCDEVPRIVATE. And
none of these says anything about getting any error statistics out.

I think i will also have to look atr procs /net/dev code to find what the
interface is. (ie ofcourse only if i dont see any other helpful posts)

arun

"Juha Laiho" <(E-Mail Removed)> wrote in message
news:bhb4v9$26v$(E-Mail Removed)-int...

> Do you actually get information on
> - late collisions
> - separate counters for one/multiple collisions
>
> on Windows?
> on Solaris?
>
> If so, could you describe where you find this info (esp. on Windows,
> so that there is some sign that at least some network adapters provide
> this data on Intel systems)?

Windows - from miniport driver directly
Solaris - what else but kstat

> >But of-course I'm limited to what the os tells me in those cases
> >whereas in Linux I can check the code and verify if the code is giving
the
> >same data as the man page claims or find some back doors if possible.

> ... and the OS is limited to the info available from the hardware.
> So, if the hardware doesn't maintain those counters, you're not going
> to get the info.

Well i dont know abt hardware maintaining the stats but drivers do
maintain them - on Linux too. Atleast an e100 drivers code i saw that
comes with my RH7.3 system does seem to store more than what is
exposed by /proc/net/dev

> >But back doors / adding my own module / patches etc is not at all
> >acceptable from an enterprise perspective. Nobody would allow a new
> >module let alone a patch in their production servers. That kinda cool
> >things can be done only on our personal machines
>
> Strange. I see installing patches as part of the maintenance practice,
> on HP-UX, Solaris and Linux just as well. Ok, in Linux-world the patches
> mostly are upgraded application or kernel packages, but that's a technical
> detail. Also, if a one-off modification to a system is required, it is
> done -- but it is not done lightly, and not until other possibilities to
> solve the problem at hand have been exhausted.

You missed the operative word - <my own>. Not a single enterprise would
be really happy to add a custom patch/module.

> >I just hope Linux matures fast enough with regards to the manageability
> >(there would be other such aspects I guess, like volume management
> >and stuff I hear people talkin abt) and enterprise aspects fast enough
>
> My greatest wish is to have in-kernel instrumentation at the level of
> HP-UX. And of course the applications to access the instrumentation
> data (like gpm and friends on HP-UX). But then, this same applies to
> Solaris, so Linux isn't dragging tha far behind.

And i thought kstat and its sysinfo functions were good. Plus the microstate
accounting is really better for averaging and sampling stuff (theoretics)
HP is better ? what does it have

arun

"Juha Laiho" <(E-Mail Removed)> wrote in message
news:bhb4v9$26v$(E-Mail Removed)-int...
> "arun" <(E-Mail Removed)> said:
> >
> >"Juha Laiho" <(E-Mail Removed)> wrote in message
> >news:bh8pg9$rlm$(E-Mail Removed)-int...
> >> "arun" <(E-Mail Removed)> said:
> >> >Thats just what i wanted to know - is there any way i can get hold of
> >> >these stats in Linux ?
> >>
> >> Not that I know of. The only place where I've seen "late collisions"
> >> reported was a Fluke LAN analyzer -- so I can only guess that regular
> >> network adapters do not maintain separate counters for these, but just

Well check what a particular driver code that came with my RH7.3 says
The code creates a proc entry and stuff and these are the stuff it exposes
Now i have to find where that entry is created and whether it is maintained
by all drivers (I assume it creates a proc entry from a create_proc_entry
call)

static e100_proc_entry e100_proc_list[] = {
{"Description", read_descr, 0, 0},
{"Permanent_HWaddr", read_permanent_hwaddr, 0, 0},
{"Part_Number", read_part_number, 0, 0},
{"\n",},
{"Rx_TCP_Checksum_Good", read_gen_ulong, 0, ~0},
{"Rx_TCP_Checksum_Bad", read_gen_ulong, 0, ~0},
{"Tx_TCP_Checksum_Good", read_gen_ulong, 0, ~0},
{"Tx_TCP_Checksum_Bad", read_gen_ulong, 0, ~0},
{"\n",},
{"Tx_Abort_Late_Coll", read_gen_ulong, 0, bdp_drv_off(tx_late_col)},
{"Tx_Deferred_Ok", read_gen_ulong, 0, bdp_drv_off(tx_ok_defrd)},
{"Tx_Single_Coll_Ok", read_gen_ulong, 0, bdp_drv_off(tx_one_retry)},
{"Tx_Multi_Coll_Ok", read_gen_ulong, 0, bdp_drv_off(tx_mt_one_retry)},
{"Rx_Long_Length_Errors", read_gen_ulong, 0, ~0},
{"\n",},
{"Tx_Flow_Control_Pause", read_gen_ulong, 0, bdp_drv_off(xmt_fc_pkts)},
{"Rx_Flow_Control_Pause", read_gen_ulong, 0, bdp_drv_off(rcv_fc_pkts)},
{"Rx_Flow_Control_Unsup", read_gen_ulong, 0,
bdp_drv_off(rcv_fc_unsupported)},
{"\n",},
{"Tx_TCO_Packets", read_gen_ulong, 0, bdp_drv_off(xmt_tco_pkts)},
{"Rx_TCO_Packets", read_gen_ulong, 0, bdp_drv_off(rcv_tco_pkts)},
{"\n",},
{"Rx_Interrupt_Packets", read_gen_ulong, 0, bdp_drv_off(rx_intr_pkts)},
{"Rx_Polling_Packets", read_gen_ulong, 0, bdp_drv_off(rx_tasklet_pkts)},
{"Polling_Interrupt_Switch", read_gen_ulong, 0,
bdp_drv_off(poll_intr_switch)},
{"Identify_Adapter", 0, write_blink_led_timer, 0},
{"", 0, 0, 0}

arun

"arun" <(E-Mail Removed)> wrote
> "Juha Laiho" <(E-Mail Removed)> wrote in message
> > >> Not that I know of. The only place where I've seen "late collisions"
> > >> reported was a Fluke LAN analyzer -- so I can only guess that regular
> > >> network adapters do not maintain separate counters for these, but
just
>
> Well check what a particular driver code that came with my RH7.3 says
> The code creates a proc entry and stuff and these are the stuff it exposes
> Now i have to find where that entry is created and whether it is
maintained
> by all drivers (I assume it creates a proc entry from a create_proc_entry
> call)

WELL, for a one particular machine which i found had the particular driver
loaded e1000 had created a directory called PRO_LAN_Adapters under
/proc/net and has all the info i wanted

But i dont see the same in an old 7.1 machine i have. And its going to be
tricky to read the stats from a program if the drivers are all going to
create
sub-directories with their own names under /proc/net

Now all i need is for someone from Sycld etc to tell me what is the status
on this kindof behaviour from drivers and whether that can be relied upon

Thanks
arun

"arun" <(E-Mail Removed)> wrote in message
news:bhd9m9$vrp42$(E-Mail Removed)...
>
> WELL, for a one particular machine which i found had the particular driver
> loaded e1000 had created a directory called PRO_LAN_Adapters under
> /proc/net and has all the info i wanted

Probably the driver is special - the installation came with a Dell server
and
i guess they had the special driver put in or some. Anyway i dont see it on
other RH7.3 distros even comparatively well managed ones

So i guess thats end of line for getting info from proc. Atleast it proves
that
if something like this was already present, the module i saw wouldnt have
been trying to do stuff in a non-standard way.

arun