#2 Performance problems on Sharppcap?

[Matias Cortez]

I’m experiencing some performance problems when using SharpPcap. What I wanted to do is to forward packets that I receive in a given network interface. I noticed that the delay between the time a packet is received and the time packet is sent out is 700 mseconds.

If you send packets without capturing them, these packets are sent with very little delay. I figured out that performance problem takes place when the device is capturing packets. If we put the device into promiscuous mode and then try to fordward the packets that are received, the packets get delayed.

I was looking for something to prioritize the sending of packets but I didn’t found anything on SharpPcap.

I’m building a real time application so I need the packets to be sent out as soon as possible, with little delay.

I don’t know if Sharppcap is suitable for this kind of application. Should I use directly Winpcap?

Could someone please provide support on this?

Thanks in advance.

[Chris Morgan]

Hello.

Are you referring to milliseconds or microseconds?

Have you looked at reducing the timeout value when you are opening the device? It may be that your traffic rate is low and not causing a callback until the timeout vs hitting the size trigger.

Sharppcap is likely fast enough for your use. It is intended to be a very thin layer on top of winpcap and in fact uses winpcap as it's low level implementation. Any performance hit you might see would be due to either adapter/capture settings or from .net and the .net overhead is likely to be low on fast modern computers

Chris

Chris

[Matias Cortez]

Hi Chris, thank you for the quick response. I'm referring to milliseconds. I need the device to be opened all the time, so I don't need to use a timeout when opening the device.

I've also tested sending high load of traffic and I still have a significant delay (700 milliseconds).

What do you recommend for reducing the delay? Is it possible that you can test a simple application that I have to see the problem?

Thanks a lot for your support,

Regards,

Matias.-

[Chris Morgan]

I don't think we are talking about the same timeout.

The timeout I'm referring to is passed when a device is opened and has to do with when your application will receive packets. Look at the overloads when opening devices or the device properties. I can't recall which might be easiest but I can look on a pc this evening if you can't figure it out.

This URL discusses the timeout I'm referring to http://www.winpcap.org/pipermail/winpcap-users/2005-November/000463.html

Chris

[Matias Cortez]

I think you are talking about the read_timeout:
Open(DeviceMode mode, int read_timeout)

This is from the documentation:

read_timeout: Specifies the read timeout, in milliseconds. A read on the adapter (for example, using the GetNextPacket() function) will always return after read_timeout milliseconds, even if no packets are available from the network. read_timeout also defines the interval between statistical reports if the adapter is in statistical mode (see the Gathering statistics on the network traffic section). Setting read_timeout to 0 means no timeout, a read on the adapter never returns if no packets arrive. A -1 timeout on the other side causes a read on the adapter to always return immediately.

I'll be testing with different values for the read_time.

Thanks!

[Chris Morgan]

Any updates on this? Was it the default read timeout that was being used in the case where the device is opened with Open(DeviceMode mode) and not Open(DeviceMode mode, int read_timeout)?

Chris

[Nobody/Anonymous]

hRaHwF wpgsarpleunr, [url=http://haojxzanhugd.com/]haojxzanhugd[/url], [link=http://kdtdpdaahcqw.com/]kdtdpdaahcqw[/link], http://vtjethbnzhjp.com/