Re: Network stack/ethernet driver issues
Re: Network stack/ethernet driver issues
- Subject: Re: Network stack/ethernet driver issues
- From: email@hidden
- Date: Wed, 9 Apr 2008 17:44:24 -0700 (PDT)
- Importance: Normal
So this is considered acceptable behavior/performance and I shouldn't
bother filing a bug? I realize that UDP is an "unreliable" transport but
in this case the packets aren't even making it to the network stack to be
discarded. In my application packet retransmission is not feasible. It
seems to me that the problem is that the secondary interrupt to service
the ethernet driver sometimes isn't scheduled often enough to keep up with
the amount of data I'm generating. Assuming an RX receive ring buffer
size of 1024 packets (I think thats what the linux driver uses) in order
for an overflow to happen more than 20ms (1024 packets/50000 packets/sec)
would have to go by between when the ethernet device receives a packet and
when the interrupt is processed. And also somehow things are being
handled inefficiently (compared to the Linux case). Did you see the rest
of my original message ?
If frequently dropping packets with only 40% of the available bandwidth
being utilized and no load on the machine other than an application
listening for and peeking at the contents of said packets is considered OK
then I will stick to Linux for my low latency, high bandwidth network
applications (and encourage others to do likewise).
-rimas
> You do realize what the "U" in "UDP" stands for, right?
>
> Try using a reliable stream delivery mechanism instead. It would be a
> serious waste of effort to set aside a huge amount of buffer space to
> try and catch all packets of a type where it didn't matter if they
> arrived or not.
>
> -- Terry
>
> On Apr 9, 2008, at 4:39 PM, email@hidden wrote:
>> Sorry if I wasn't clear - the results I am reporting here are using
>> a test
>> program that only looks at the packet ID and then drops the packet.
>> Also
>> I get the rx buffer overrun messages even if there isn't an
>> application
>> running.
>>
>> I am using an eSATA ExpressCard and external SATA drive enclosure to
>> log
>> the data, they are more than fast enough (like I said everything works
>> fine under Linux).
>>
>> -rimas
>>
>>>
>>> On 09.04.2008, at 21:09, email@hidden wrote:
>>>
>>>> Greetings,
>>>>
>>>> Here's my situation: I have a custom piece of data logging hardware
>>>> that
>>>> generates about 50MB/sec of data and sends it out over a gigabit
>>>> ethernet
>>>> link as a steady stream of UDP packets (1k packet every ~20
>>>> microseconds,
>>>> very periodic, not bursty at all) broadcasted to the local subnet.
>>>> I want
>>>> to log all this data to disk for offline analysis. As a first
>>>> step I
>>>> wrote a program to just listen for the UDP packets and verify that
>>>> they
>>>> were all being received. This is easy to do because each packet has
>>>> a 16
>>>> bit sequence ID in it. Much to my dismay, I was unable to reliably
>>>> achieve this. I am running 10.5.2 on a 2.33 gHz MacBook Pro with
>>>> 2G of
>>>> memory. After making SO_RCVBUF big enough, I was still
>>>> occasionally
>>>> missing a block of 100+ packets at a time. Looking in the
>>>> system.log file
>>>> I realized that each dropout was correlated to a message like:
>>>>
>>>> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2:
>>>> 00000000,00000000
>>>> skgehw - cppSkDrvEvent - SK_DRV_RX_OVERFLOW: rcv fifo overflow
>>>> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2:
>>>> 00000000,00000000 sky2
>>>> - RX ring overflow -- dropped a packet
>>>>
>>>
>>> I think your problem is related to the fact that your userspace
>>> application can't keep up with the sent data from the kernel and thus
>>> the buffer in the kernel overruns. 50MBytes/sec of data is quite a
>>> bit
>>> and because your application writes it to disk, you need disks which
>>> can write that fast (my MacBook Pro disk can only handle something
>>> like 35MB/sec) If they are not as fast, you will naturally run out
>>> of
>>> buffer space at some time. I would suggest you redo this experiment
>>> with a striped array of firewire 800 disks.
>>>
>>> If you of course only write it to memory, its a different story.
>>> You can test this, by writing a sample application which only reads
>>> the id and drops the packet without doing anything else and see if
>>> that still doesn't keep up. You might have to think about how you
>>> read
>>> the UDP packets and if there's anything you can do there to improve
>>> that speed.
>>>
>>> I believe your problem however is simply disk speed.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Andreas Fink
>>>
>>> Fink Consulting GmbH
>>> Global Networks Schweiz AG
>>> BebbiCell AG
>>>
>>> ---------------------------------------------------------------
>>> Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333
>>> Address: Clarastrasse 3, 4058 Basel, Switzerland
>>> E-Mail: email@hidden
>>> www.finkconsulting.com www.global-networks.ch www.bebbicell.ch
>>> ---------------------------------------------------------------
>>> ICQ: 8239353 MSN: email@hidden AIM: smsrelay Skype: andreasfink
>>> Yahoo: finkconsulting SMS: +41792457333
>>>
>>> http://a-fink.blogspot.com/ A developers view about iPhone SDK
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Darwin-kernel mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden