ada sockets question

ada sockets question

[Vladimir Bednikov]

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

Re: ada sockets question

[Marc A. Criley]

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

Re: ada sockets question

[Ted Dennison]

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

Re: ada sockets question

[Vladimir Bednikov]

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

Re: ada sockets question

[tmoran]

>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.

Re: ada sockets question

[Ted Dennison]

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

Test message. Please ignore.

[Mário Amado Alves]

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