Improving socket performance,
Christopher Crotty
I inherited a rather large MFC application and need to add an ability to
retrieve a large file ( ~ 100Mbytes) from an embedded target. The target
will be sending the data to me at roughly 10 Mbits/second. We are direct
connected via a crossover cable and linked at 100 Mbits/second. The data
needs to come via UDP, so we have added a sequence number to check for
dropped packets.
I tried to just put a CSocket based object in a separate thread, but unless
I put the thread at the REALTIME priorty class with the highest priority,
the socket would not keep up. Even then if a user did anything else with the
OS, then packets would get dropped.(This test was just receiving on the
socket and dropping the data on the floor. Eventually I need to throw the
data to a file).
Sorry for the long-winded setup, but here is the question, Will I see a
large performance improvement by moving out of the CSocket MFC class to a
RAW_SOCKET or just to a Berkely-style SOCKET struct with C-calls?
I was looking at using the overlapped IO capabilities, to provide a memory
mapped file as the input buffer, but I need to support Win9X as well as
2000 and up. From what I read, Win9X does not support overlapped IO for
files and sockets.
Anyone have any suggestions on speed up the receive capabilities?
Thanks in Advance,
Chris
cro...@rcn.com
SenderX
> mapped file as the input buffer, but I need to support Win9X as well as
> 2000 and up. From what I read, Win9X does not support overlapped IO for
> files and sockets.
>
> Anyone have any suggestions on speed up the receive capabilities?
Win98> does support overlapped io for files, sockets, ect...
There are some limits, such as not being able to have more than one pending
wsarecv at any given time per. socket.
My AppCore Framework exposes the Socket Peer API which can run on Win98>. It
uses overlapped io with my pseudo iocp system for completion.
The socket peer api uses tcp, but can be adapted to use udp.
I can show you some source if you want.
David Schwartz
> I tried to just put a CSocket based object in a separate thread, but unless
> I put the thread at the REALTIME priorty class with the highest priority,
> the socket would not keep up. Even then if a user did anything else with the
> OS, then packets would get dropped.(This test was just receiving on the
> socket and dropping the data on the floor. Eventually I need to throw the
> data to a file).
Does your thread loop on a blocking WSARecv? Do you enlarge the receive
buffer?
> Sorry for the long-winded setup, but here is the question, Will I see a
> large performance improvement by moving out of the CSocket MFC class to a
> RAW_SOCKET or just to a Berkely-style SOCKET struct with C-calls?
Probably not, unless you make other changes at the same time.
> I was looking at using the overlapped IO capabilities, to provide a memory
> mapped file as the input buffer, but I need to support Win9X as well as
> 2000 and up. From what I read, Win9X does not support overlapped IO for
> files and sockets.
Your plan strikes me as a bad one. UDP does not guarantee in-order
reception or that there won't be drops or duplicates, so writing to a
memory-mapped file seems silly. I would, however, divorce the UDP
receive thread from the file write thread.
What's your IO loop look like now?
DS
Christopher Crotty
"David Schwartz" <dav...@webmaster.com> wrote in message
news:3DEC1332...@webmaster.com...
> Christopher Crotty wrote:
>
> > I tried to just put a CSocket based object in a separate thread, but
unless
> > I put the thread at the REALTIME priorty class with the highest
priority,
> > the socket would not keep up. Even then if a user did anything else with
the
> > OS, then packets would get dropped.(This test was just receiving on the
> > socket and dropping the data on the floor. Eventually I need to throw
the
> > data to a file).
>
> Does your thread loop on a blocking WSARecv? Do you enlarge the receive
> buffer?
Yes, I am running a blocking WSARecv call. I have added a receive timeout
(for catching user stop requests) to the socket.
I'm playing with changing the buffer sizes now. Currently the target is
sending me 1300 byte packets of data. I'm assuming that by calling receive
with a buffer several packets in size, it will save some interrupt switching
and notification time.
Chris Pearson
That is the nature of UDP. Better app performance is not the answer. You
can't possibly control all the conditions that might cause the lose of UDP
datagrams, since they can be dropped by any network element (e.g. sending or
receiving IP stack or NIC). Even if you managed to greatly reduce the loss
rate, you could never reach 100% reliability. So you'd need a resend
strategy. Rather than designing your own reliable UDP, if you have the
option, have the embedded host send the data using TCP.
-- CCP
"Christopher Crotty" <cro...@rcn.com> wrote in message
news:asei88$sgj$1...@bob.news.rcn.net...
SenderX
> > large performance improvement by moving out of the CSocket MFC class to
a
> > RAW_SOCKET or just to a Berkely-style SOCKET struct with C-calls?
>
The CSocket class is not efficent, and is a bad idea overall...
If you move the socket code from CSocket && MFC to C using the winsock
api... You will notice a performance increase in the amount of processor
usage and throughput...
> > I was looking at using the overlapped IO capabilities, to provide a
memory
> > mapped file as the input buffer, but I need to support Win9X as well as
> > 2000 and up. From what I read, Win9X does not support overlapped IO for
> > files and sockets.
Yes, using a memory mapped file with overlapped io is the most efficent
application-level method to transfer data.
You can use overlapped io with win98>, I suggest learning how to use it...
David Schwartz
> > > I was looking at using the overlapped IO capabilities, to provide a
> memory
> > > mapped file as the input buffer, but I need to support Win9X as well as
> > > 2000 and up. From what I read, Win9X does not support overlapped IO for
> > > files and sockets.
>
> Yes, using a memory mapped file with overlapped io is the most efficent
> application-level method to transfer data.
For TCP. But he was talking about UDP.
How would overlapped I/O to a memory mapped file work when yuo drop a
packet? Or receive the same packet twice?
DS
John McClenny
says...
> > if a user did anything else with the OS, then packets would get dropped.
>
> That is the nature of UDP. Better app performance is not the answer. You
> can't possibly control all the conditions that might cause the lose of UDP
> datagrams, since they can be dropped by any network element (e.g. sending or
> receiving IP stack or NIC). Even if you managed to greatly reduce the loss
> rate, you could never reach 100% reliability. So you'd need a resend
> strategy. Rather than designing your own reliable UDP, if you have the
> option, have the embedded host send the data using TCP.
On a crossover cable, with a fast machine? As long as the application is
properly coded and the system is not used for a lot of other work, there
shouldn't be ANY dropped packets. Of course, storing the data on disk
adds overhead. But 10 mbps is only 1.2 MB/s, which isn't a very fast
data rate for modern PCs. I have run much faster multicast UDP data
rates across a (fast) switched LAN without ANY dropped packets over
several days even on Win98.
What do you do on lost packets? Abort? Retry?
That aside, Chris's advice to use TCP is correct. If you are really
sending a file, I would use TCP. If the source is sending realtime
captured data and can't slow down for TCP/IP
If you can't control the source side and need to support Win98,
overlapped I/O is your friend. Junk the MFC crap and move to an
overlapped model - you will see major gains in performance and should be
able to easily handle the low data rate you need. It isn't that
complicated to get working and is much faster than CSocket.
SenderX
I don't really work with UDP too much, unless the protocol is ok with
dropping old data and just getting the most current information.
Maybe I should of said...
Sending static or dynamic data that is packed in a memapped-files using TCP
or UDP is the most efficient
application-level method to transfer data via. winsock.
Receiving the data is a different story, cause of udp.
> How would overlapped I/O to a memory mapped file work when yuo drop a
> packet? Or receive the same packet twice?
Well, I would assume you include file offsets in the file transfer packets
so the other app knows where to write them to disk... So if you get a
duplicate, it will just overwrite the data that's already there. After the
app that sends the file knows that it is done sending, it would wait for the
other app to send requests for the file offsets that it did not get?
Kilgaard
news:8pbH9.223812$QZ.34539@sccrnsc02...
> > For TCP. But he was talking about UDP.
>
> > packet? Or receive the same packet twice?
>
> Well, I would assume you include file offsets in the file transfer packets
> so the other app knows where to write them to disk... So if you get a
> duplicate, it will just overwrite the data that's already there. After the
> app that sends the file knows that it is done sending, it would wait for
the
> other app to send requests for the file offsets that it did not get?
Which sounds incredibly like what TCP does.
Peter Duniho
news:asjmli$r77ba$2...@ID-154877.news.dfncis.de...
> Which sounds incredibly like what TCP does.
You can get very similar functionality from TCP, but the algorithm "SenderX"
suggests is hardly like what TCP is actually using to get that
functionality. An algorithm like what "SenderX" is suggesting could deal
with the data being delivered in practically any order, at any time. TCP
will still need the data to be sent in something at least approximating
linear order; it's not going to hang on to the last ten bytes of a several
hundred megabyte transmission that's just starting, for example.
Pete
Kilgaard
news:uuqojn1...@corp.supernews.com...
Depends on the size of your receive window really, but you're right, you are
not likely to have an "several hundred megabyte" window.
What I was really trying to say was that TCP will provide the same
functionality. Why reinvent the wheel?
Peter Duniho
> What I was really trying to say was that TCP will provide the same
> functionality. Why reinvent the wheel?
You're not reinventing the wheel. A variety of things can be done
transferring files using UDP like this that cannot be done using TCP. For
example, one could get statistics on percentage packet loss. Or you could
use the the same UDP socket to receive multiple files at the same time.
Like I said, while the there are similarities in functionality, there are
significant differences in the underlying implementation. It's NOT the same
as TCP.
Pete
SenderX
> functionality. Why reinvent the wheel?
The OP said he has to use UDP to retrieve 100MB> files ;)
I suggested a solution, that I think will work ;)
Chris Pearson
> properly coded and the system is not used for a lot of other work, there
> shouldn't be ANY dropped packets.
This is simplistic. Windows (any flavor) is a huge and amazingly complex
collection of software. You never know when it will start some expensive
background process (e.g. swap pages, collect garbage, compact files, create
indices, run a scheduled task, launch an COM server, etc., etc.). Just
launching an app can monopolize the hard drive read heads for seconds. I
don't mean to rant, but you simply can not with any predictability prevent
Windows or some application from monopolizing the processor, network
adapter, I/O bus, or hard drive long enough to lose IP packets.
> I have run much faster multicast UDP data
> rates across a (fast) switched LAN without ANY dropped packets over
> several days even on Win98.
This is so dependant on system capabilities (processor speed, bus speed,
memory speed, NIC speed, relative load, blah, blah, blah) as to be almost
meaningless. Yeah, it worked for you, but you can't generalize that to
other systems. (And I doubt you were doing anything else significant with
either system during the transfer.) And RFI happens, dude! Bottom line is
you simply can not write a reliable file transfer process using straight UDP
without some sort of resend strategy.
But you might be able to write a "reliable UDP" specifically for the
cross-over configuration that will outperform TCP, because you won't need to
be doing slow-start, delayed ACK, naggle and other TCP "good netizen"
behavior. You can also do selective resend. That might be an interesting
project!
-- Chris
"John McClenny" <spa...@bebu.com> wrote in message
news:MPG.1856a71dc...@news.supernews.com...
Alun Jones
Of course, if he was saying that he has to use a bicycle to transport cement,
we'd still suggest that he switch to using a truck.
Just because he's set on using UDP, doesn't mean that TCP isn't a good
suggestion for solving his underlying problem. Sometimes the question asked
is not the question best answered - sometimes the basic underlying assumptions
need to be checked. There may very well be reasons for using UDP, but it's
worth making sure that the OP doesn't end up essentially re-inventing TCP but
doing it less efficiently over UDP!
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.
SenderX
> suggestion for solving his underlying problem.
Agreed. Use TCP if at all possible.
I gave a UDP solution that could work cause I think he is forced to use udp:
OP>> The data needs to come via UDP, so we have added a sequence number to
check for dropped packets.
I am sure the OP wishes he could use TCP =), but the OP is probably tired of
hearing " just use TCP " when he has to use UDP??
Skybuck Flying
"Alun Jones" <al...@texis.com> wrote in message
news:2snH9.537$4J6.60...@newssvr12.news.prodigy.com...
> In article <wagH9.226839$QZ.35656@sccrnsc02>, "SenderX" <x...@xxx.com>
wrote:
> >> What I was really trying to say was that TCP will provide the same
> >> functionality. Why reinvent the wheel?
> >
> >The OP said he has to use UDP to retrieve 100MB> files ;)
> >
> >I suggested a solution, that I think will work ;)
>
> Of course, if he was saying that he has to use a bicycle to transport
cement,
> we'd still suggest that he switch to using a truck.
>
> Just because he's set on using UDP, doesn't mean that TCP isn't a good
> suggestion for solving his underlying problem. Sometimes the question
asked
> is not the question best answered - sometimes the basic underlying
assumptions
> need to be checked. There may very well be reasons for using UDP, but
it's
> worth making sure that the OP doesn't end up essentially re-inventing TCP
but
> doing it less efficiently over UDP!
Gjeee... let s make sure it isn't more efficient than TCP otherwise Alun has
to ditch TCP and start learning UDP :)