From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b3cf7df9853d8ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-05 08:30:45 PST Path: archiver1.google.com!news2.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9hrtm0$9o6$1@fang.dsto.defence.gov.au> <7wk07.5702$Kf3.48587@www.newsranger.com> <9i0p05$ic4$1@fang.dsto.defence.gov.au> Subject: Re: ada sockets question Message-ID: <5B%07.8050$Kf3.80616@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 05 Jul 2001 11:20:33 EDT Organization: http://www.newsranger.com Date: Thu, 05 Jul 2001 15:20:33 GMT Xref: archiver1.google.com comp.lang.ada:9474 Date: 2001-07-05T15:20:33+00:00 List-Id: In article <9i0p05$ic4$1@fang.dsto.defence.gov.au>, Vladimir Bednikov says... > >I am trying to transfer 32 lots of 2048 data samples which are in signed >short int format. One way i did it was to create a string to hold each >individual 2048 samples and send it. This takes 32 seconds to send the 32 >blocks, I want it sent in less than one second. >I tried to combine all 32 blocks of 2048 samples into one string and send it >in one go but got a core dump when I tried to use the stream_listener example >to receive the data. >Is there a max limit on the size of the packets that I can send? A lot depends on whether you are using TCP or UDP. UDP's maximum packet size is about 64K. If you use the "sockets" interface (as practicaly everyone does), you are only allowed 8k. I believe TCP has this limit as well, but since it is stream-oriented, it can just keep feeding in more data until it is done (and so can you). If you send UDP more than the network's "Maximum Transmission Unit" (usually a smidge under 1500 bytes) it will get fragmented. The fragments will be reasembled properly on the other end, so no worries there. However, if any part of that fragmented series of packets experiences a problem, the whole damn thing has to be resent. TCP handles "fragmenting" at its own level (it calls it "segmenting"), so that if something goes wrong, only the individual packet (segment) with the problem needs to be resent. TCP actually will do the resend too, whereas UDP just throws the data on the floor and goes on. TCP has lots of timing issues. The thing to realize about TCP is that is was designed to be efficient for lots of small transmissions (like might occur if you are typing in a telnet connection). It can do "bulk" transmissions too, but its helps to reconfigure a few things first. For instance, by default it likes to delay data sends on the connection until it has an acknowlegement message that it can piggyback the data onto. If no such message is forthcomming, there can be a significant delay (usually 200ms or so) while it waits for one. Also, if you send a lot of data before the recipient can get around to dealing with it, there are a couple of different places the send can get blocked until the recepient gets around to reading some of the data. (eg: you probably don't have enough mbufs on your socket to store one entire transmission) There are ways to configure things to minimize this, if you know what you are doing. So you say that each block is taking one second to transmit? The fact that your timing is such (large) round numbers to my mind is *very* suspcious. I would guess you are running into a timer somewhere. As you can see, the network code (especially TCP) is chock full of timers. If you are serious about finding the cause of the slowness, I'd say the best thing to do would be to get a network monitor and connect it to the network segment one of the machines is running on. Odds are the kind folks who keep your network running have one, and may even show you how to use it (for a suitable inducement, of course). It might also pay to get a good TCP/IP reference. "TCP/IP Illustrated" is wonderful (volume 2 includes most of the sources for the stack!) but costs a little over $130 (US) for the two-volume set. There is a *lot* that can go wrong with network transmissions (particularly on a large busy network). Trying to blindly blame throughput problems on anything non-network related, when in fact you haven't the foggiest clue what is going wrong, seems more than a bit premature. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com