Sending ethernet frames one after another

Sending ethernet frames one after another

[Karel Kulhavy]

Hello

I have written a software to test connected optical datalink in loopback
mode which works by sending a burst of e. g. 1024 raw Ethernet frames
directly to that interface, then waiting a little bit, and counting from
ifconfig how many were received.

Some people report a problem that on their eepro100 in IBM Thinkpad, the
program (probably sendto) is returning error "No buffer space available".

Why doesn't the sendto block instead? Does it mean that I cannot use
this testing mode with that card? I need to send as fast as possible,
because it's necessary to constantly transmit, as the link must be
tested in load going in both directions simultaneously, to catch
possible crosstalks.

Or is that an error that should be handled by the application? In which
way, then?

Regards,

CL<

Re: Sending ethernet frames one after another

[Richard B. Johnson]

On Tue, 5 Jul 2005, Karel Kulhavy wrote:

> Hello
>
> I have written a software to test connected optical datalink in loopback
> mode which works by sending a burst of e. g. 1024 raw Ethernet frames
> directly to that interface, then waiting a little bit, and counting from
> ifconfig how many were received.
>
> Some people report a problem that on their eepro100 in IBM Thinkpad, the
> program (probably sendto) is returning error "No buffer space available".
>
> Why doesn't the sendto block instead? Does it mean that I cannot use
> this testing mode with that card? I need to send as fast as possible,
> because it's necessary to constantly transmit, as the link must be
> tested in load going in both directions simultaneously, to catch
> possible crosstalks.
>

If sendto is used on a data-gram socket, it may just dump
extra packets on the floor. If you have a connected socket,
sendto will return an error when no buffers are available.

If you want RELIABLE communication, then you use a connected
stream socket and send() or write(). These handle transmission
problems transparently.

> Or is that an error that should be handled by the application? In which
> way, then?
>

Generally, it is least expensive as far as performance is concerned
if you let the kernel handle errors, retries, duplicate packets, etc.
That's what you get with a connected stream socket. However, since
every packet is ACKed, the round-trip time can be a performance
killer. So, a private protocol for talking through satellites which
have awful round-trip time might be to number packets at the application
level, send everything, then query the receiver software about the
missing packets. This continues until all the packets have been
received.

> Regards,
>
> CL<
>




Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: Sending ethernet frames one after another

[jscottkasten]

--- Karel Kulhavy <clock@twibright.com> wrote:

> Hello
> 
> I have written a software to test connected optical
> datalink in loopback
> mode which works by sending a burst of e. g. 1024
> raw Ethernet frames
> directly to that interface, then waiting a little
> bit, and counting from
> ifconfig how many were received.
> 
> Some people report a problem that on their eepro100
> in IBM Thinkpad, the
> program (probably sendto) is returning error "No
> buffer space available".
> 
> Why doesn't the sendto block instead? Does it mean
> that I cannot use

Are you sure that it is the program getting this
error?  Have you traced this to a bad return from the
sendto function?

I have a couple thoughs.  One issue with the memory is
that going in and out of the driver, the network
buffers are DMA quality memory (meaning hardware
accessable address space, and contiguous physically,
rather than virtually).  When things get churned up it
can be difficult to get memory that fits those
criteria.

-S-