|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Thanks,
Vincent
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:
@apple.com
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
| References: | |
| >Network stack/ethernet driver issues (From: email@hidden) | |
| >Re: Network stack/ethernet driver issues (From: Andreas Fink <email@hidden>) | |
| >Re: Network stack/ethernet driver issues (From: email@hidden) | |
| >Re: Network stack/ethernet driver issues (From: Terry Lambert <email@hidden>) | |
| >Re: Network stack/ethernet driver issues (From: email@hidden) |
| Home | Archives | Terms/Conditions | Contact | RSS | Lists | About |
Visit the Apple Store online or at retail locations.
1-800-MY-APPLE
Contact Apple | Terms of Use | Privacy Policy
Copyright © 2011 Apple Inc. All rights reserved.
