* ada sockets question @ 2001-07-03 7:46 Vladimir Bednikov 2001-07-03 12:42 ` Marc A. Criley 2001-07-03 14:19 ` Ted Dennison 0 siblings, 2 replies; 9+ messages in thread From: Vladimir Bednikov @ 2001-07-03 7:46 UTC (permalink / raw) Hi all, I am writing a RT application on an SGI using gnat3.13p. I have downloaded the adasockets package version 0.1.13 and am using it, but it is very slow. Is there a fast sockets package or do I have to call c sockets. Thanks in advance ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ada sockets question 2001-07-03 7:46 ada sockets question Vladimir Bednikov @ 2001-07-03 12:42 ` Marc A. Criley 2001-07-03 14:19 ` Ted Dennison 1 sibling, 0 replies; 9+ messages in thread From: Marc A. Criley @ 2001-07-03 12:42 UTC (permalink / raw) Vladimir Bednikov wrote: > > Hi all, > > I am writing a RT application on an SGI using gnat3.13p. I have > downloaded the adasockets package version 0.1.13 and am using it, > but it is very slow. Is there a fast sockets package or do I have to > call c sockets. Take a look at the implementation: AdaSockets calls C sockets. Marc A. Criley Senior Staff Engineer Quadrus Corporation www.quadruscorp.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ada sockets question 2001-07-03 7:46 ada sockets question Vladimir Bednikov 2001-07-03 12:42 ` Marc A. Criley @ 2001-07-03 14:19 ` Ted Dennison 2001-07-05 3:56 ` Vladimir Bednikov 2001-07-06 15:11 ` Test message. Please ignore Mário Amado Alves 1 sibling, 2 replies; 9+ messages in thread From: Ted Dennison @ 2001-07-03 14:19 UTC (permalink / raw) In article <9hrtm0$9o6$1@fang.dsto.defence.gov.au>, Vladimir Bednikov says... >I am writing a RT application on an SGI using gnat3.13p. I have >downloaded the adasockets package version 0.1.13 and am using it, >but it is very slow. Is there a fast sockets package or do I have to >call c sockets. What is slow about it? Are you certain the "slowness" has anything to do with the Ada code? I'd have trouble believing that there's anything going on in the Ada bindings that takes anywhere close to the same amount of time as the network transmission itself. Even if it does something stupid like make an extra copy of the data being transmitted, that's going to be immensly faster than copying the same data over the network. I suppose you could get even dumber by using dynamic allocation and deallocation... --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ada sockets question 2001-07-03 14:19 ` Ted Dennison @ 2001-07-05 3:56 ` Vladimir Bednikov 2001-07-05 5:56 ` tmoran 2001-07-05 15:20 ` Ted Dennison 2001-07-06 15:11 ` Test message. Please ignore Mário Amado Alves 1 sibling, 2 replies; 9+ messages in thread From: Vladimir Bednikov @ 2001-07-05 3:56 UTC (permalink / raw) 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? Bye all "Ted Dennison" <dennison@telepath.com> wrote in message news:7wk07.5702$Kf3.48587@www.newsranger.com... > In article <9hrtm0$9o6$1@fang.dsto.defence.gov.au>, Vladimir Bednikov says... > >I am writing a RT application on an SGI using gnat3.13p. I have > >downloaded the adasockets package version 0.1.13 and am using it, > >but it is very slow. Is there a fast sockets package or do I have to > >call c sockets. > > What is slow about it? Are you certain the "slowness" has anything to do with > the Ada code? I'd have trouble believing that there's anything going on in the > Ada bindings that takes anywhere close to the same amount of time as the network > transmission itself. > > Even if it does something stupid like make an extra copy of the data being > transmitted, that's going to be immensly faster than copying the same data over > the network. I suppose you could get even dumber by using dynamic allocation and > deallocation... > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ada sockets question 2001-07-05 3:56 ` Vladimir Bednikov @ 2001-07-05 5:56 ` tmoran 2001-07-05 15:20 ` Ted Dennison 1 sibling, 0 replies; 9+ messages in thread From: tmoran @ 2001-07-05 5:56 UTC (permalink / raw) >I am trying to transfer 32 lots of 2048 data samples which are in signed >short int format. So you want to send 128K bytes, right? Which should go pretty fast over anything speedier than a modem. >Is there a max limit on the size of the packets that I can send? Are you using datagrams or stream sockets? The former have a maximum size, but ought to just ignore data beyond that size. The latter are byte, not record, oriented so the breaking into packets on a send, and the reassembly on a read, should be transparent. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ada sockets question 2001-07-05 3:56 ` Vladimir Bednikov 2001-07-05 5:56 ` tmoran @ 2001-07-05 15:20 ` Ted Dennison 1 sibling, 0 replies; 9+ messages in thread From: Ted Dennison @ 2001-07-05 15:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Test message. Please ignore. 2001-07-03 14:19 ` Ted Dennison 2001-07-05 3:56 ` Vladimir Bednikov @ 2001-07-06 15:11 ` Mário Amado Alves 1 sibling, 0 replies; 9+ messages in thread From: Mário Amado Alves @ 2001-07-06 15:11 UTC (permalink / raw) To: comp.lang.ada Test message. Please ignore. -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150 PORTO, Portugal mob 351+939354002 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Test message. Please ignore. @ 2003-06-09 10:27 Marin David Condic 2003-06-09 13:13 ` Frank J. Lhota 0 siblings, 1 reply; 9+ messages in thread From: Marin David Condic @ 2003-06-09 10:27 UTC (permalink / raw) Test message. Please ignore. -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "In general the art of government consists in taking as much money as possible from one class of citizens to give to the other." -- Voltaire ====================================================================== ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Test message. Please ignore. 2003-06-09 10:27 Marin David Condic @ 2003-06-09 13:13 ` Frank J. Lhota 0 siblings, 0 replies; 9+ messages in thread From: Frank J. Lhota @ 2003-06-09 13:13 UTC (permalink / raw) pragma Suppress( Test_Posts ); ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-06-09 13:13 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-03 7:46 ada sockets question Vladimir Bednikov 2001-07-03 12:42 ` Marc A. Criley 2001-07-03 14:19 ` Ted Dennison 2001-07-05 3:56 ` Vladimir Bednikov 2001-07-05 5:56 ` tmoran 2001-07-05 15:20 ` Ted Dennison 2001-07-06 15:11 ` Test message. Please ignore Mário Amado Alves -- strict thread matches above, loose matches on Subject: below -- 2003-06-09 10:27 Marin David Condic 2003-06-09 13:13 ` Frank J. Lhota
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox