-1

Using WinPcap I crafted a series of custom UDP packets and injected them into the Ethernet layer.

I sent 1000 packets, 1440 bytes each. It takes 2.1 sec for 100 Mbps bandwidth.

How do I make use of full bandwidth?

sharptooth
  • 167,383
  • 100
  • 513
  • 979
krishnakumar
  • 2,187
  • 5
  • 21
  • 24

4 Answers4

1

Your throughput seems to be exactly the max you'd get for a 10 mbit connection. Sure there's no 10mbit involved anywhere ?

krosenvold
  • 75,535
  • 32
  • 152
  • 208
1

Originally I misread the question, and thought that it was a duplicate of this. But the 100Mbps makes it completely different.

Even very modest hardware should be able to saturate a 100Mbps connection with no problems - particularly if you're using 1440 byte udp packets.

As suggested by krosenvold, the figures do look suspiciously like a 10Mbps connection, rather than 100Mbps. I would check all of the links from end to end to make sure that they are at the 100Mbps that you believe them to be. Any 10Mbps link in that chain is going to be a problem.

Depending on the equipment that you're using you may find that there have been issues with link autonegotiation. Some equipment is notoriously bad, so you may find better results by turning autonegotiation off, and forcing the link speeds to 100Mbps.

And as you have a pcap file that you're using, I would suggest trying tcpreplay to do some speed testing. There are several options that tcpreplay provides to replay files at the highest possible speed. (in particular, look at this wiki entry)

If that gives you different results than you're seeing at the moment it could point to a problem with the pcap file. For example, the pcap files do contain timing information that can be used when replaying the file. If the timing in your pcap file was taken from a 10Mbps network (for example) then replaying it in real time will give you the result that you're seeing.

Community
  • 1
  • 1
Andrew Edgecombe
  • 39,594
  • 3
  • 35
  • 61
0

Make sure all devices and mediums on the data exchange route are operating at 100 mbps, a connection is only as fast as it's weakest link. Also make sure all devices (including your network card) are operating in Full-Duplex mode.

John T
  • 23,735
  • 11
  • 56
  • 82
0

What about CPU usage during the transfer?

We need to find the bottleneck. It can be the NIC/network or the CPU. Make sure that you are not "opening" the NIC for each packet.

Wrong:

loop{
   OpenDevice
   SendPacket
}

Good:

OpenDevice
loop{
 SendPacket
}
Tarnay Kálmán
  • 6,907
  • 5
  • 46
  • 57
  • ya you are right kalmi are you telling me to try multiple frames in a single packet?. – krishnakumar Mar 31 '09 at 08:53
  • um... no that wouldn't make much sense... and the packets are big enough... Could you show us some code? We don't even know yet what language you are using... or what API... – Tarnay Kálmán Apr 01 '09 at 03:34
  • hi kalmi gimme your mail id let me send my code. i m using Winpcap for this – krishnakumar Apr 03 '09 at 11:57
  • kalmi tell me how to use pcap_sendqueue_queue() in Winpcap API. instead of sending .pcap or .cap file need to send my own Raw UDP packets. – krishnakumar Apr 03 '09 at 12:00
  • Please use some online service (like pastebin.com) to share code and post the link here or just edit the question. All this is not just about helping you. It is also about letting others who run into the same problem later find the solution. – Tarnay Kálmán Apr 03 '09 at 21:40
  • You are calling pcap_open for each packet (pcap_open is expensive in my experience), don't do that. You are turning promiscuous mode on before sending the packet, and then off after sending a packet by "opening" and "closing" the device. – Tarnay Kálmán Apr 10 '09 at 17:41
  • pass the result of pcap_open to your SendPacket function and use it – Tarnay Kálmán Apr 10 '09 at 17:42
  • You might want to start a new question on how to use pcap_sendqueue_queue in the Winpcap API. That is your best bet performance-wise. – Tarnay Kálmán Apr 15 '09 at 16:31
  • hi i started as a new question – krishnakumar Apr 16 '09 at 05:29