Find the answer to your Linux question:
Results 1 to 8 of 8
Hi all, I have written a small program in userspace in Fedora 14 that reads a tick every 100ms and receives an ethernet packet immediately after every tick. I wanted ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2009
    Posts
    4

    Ethernet Packet: i7 versus core2duo


    Hi all,

    I have written a small program in userspace in Fedora 14 that reads a tick every 100ms and receives an ethernet packet immediately after every tick. I wanted to know how long after the tick the packet arrives.
    On the core2duo it took an average of 90 microseconds, but on the i7 it took an average of 300 microseconds.

    What could be the cause of this huge delay because the i7 is much faster and powerful than the core2duo pc.
    What can i do to improve the i7 reading of the packet.

    Thanks

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    There are a lot of factors involved here - not just the CPU. That said, the i7 has better ability to throttle back speed when not needed, so that can have an effect. In any case, these have to be two very different machines with different hardware, memory, cache, network, operating system configuration (probably), etc. Being able to design meaningful tests for this sort of stuff is an engineering discipline in its own right, and finding good performance engineers is not easy, nor can you just wave a magic wand to become one yourself. I built, staffed, and ran the performance engineering department for a major software company back in the 90's and I understand this stuff pretty well. We had to test complex client-server manufacturing applications on any number of hardware platforms, ranging from PC's running a real-time operating system, to massively parallel SMP HP Superdomes, multi-CPU DEC Alphas, SunOS and Solaris 32-bit and 64-bit systems, NCR x86 servers, and IBM PowerPC AIX systems. The difficulty in showing how they REALLY compared for our customers (often the system manufacturers themselves) was mind-boggling difficult.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Mar 2012
    Posts
    3
    Hi,

    Have you found a solution for this problem? I have a simple program that is expecting an ethernet packet every 26 usec. In many computers with intel cpu other than second generation i3/i5/i7, this works flawlessly( tested hardware include core 2 duo, atom D525, various configuration of first generation i3/i5/i7 both desktop cpu and mobile cpu). I have testes wide range of computers with second generation i3/i5/i7 cpus, and I constantly see either dropped packet(the packet never arrives) or the packet arrive very late eg. 2ms later from when it was originally sent. The network is on a direct cross over connection and I have tested the issue with various gigabit ethernet cards(both onboard and non onboard);. I am certain this issues is not a network device issue as I can replicate the issue on i3/i5/i7 computer while all but motherboard and cpu replaced work flawlessly on other cpu configuration. The program is written for Linux and Qnx and I see same behaviour for both operating system. What bothers me most is, even an atom cpu machine does not drop a single packet while the top of the line i7 desktop cpu with 3.4ghz drops or lags thousands of packets. My guess is, the issue has something to do with Sandy Bridge. Do you have any pointers for me?

    Thanks.

  4. $spacer_open
    $spacer_close
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    I would advise contacting Intel engineering support directly. Visit their web site. They have both direct email links to support, and user forums (I think). In any case, they will get back to you. FWIW, have you observed this behavior on more than one physical system?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Just Joined!
    Join Date
    Mar 2012
    Posts
    3
    Yes. I have tested on about 20 different second generation i3/i5/i7 physical configuration(motherboard and cpu combination). All show similar issue.

    Thanks.

  7. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    So, these are NICs integrated on the motherboard, correct? Have you tried another NIC, such as a PCI-X or similar device?
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  8. #7
    Just Joined!
    Join Date
    Mar 2012
    Posts
    3
    Not necessarily integrated NIC. I have tried itegrated NIC, PCI, PCIe and mini PCIe ethernet cards and same problem. I did not try PCI-X ethernet cards. To confirm whether this is a NIC related, I have used the same NIC on different computers, eg. I have tried the exact pci-e intel desktop gigabit NIC on a second generation i5 computer and on a first generation i5 computer and the problem will show on the second generation i5 while no problem on the first generation i5.

  9. #8
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    That's good diagnostic work. Do contact Intel about this issue, and give them as much information as you can.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •