From andro.galinovic at ericsson.com Fri Jul 28 01:48:29 2006 From: andro.galinovic at ericsson.com (Andro Galinovic (ZG/ETK/DR)) Date: Fri, 28 Jul 2006 10:48:29 +0200 Subject: [tg] Traffic Generator: UTP server question Message-ID: <44C9CF5D.4080007@ericsson.com> Hi. I'm using your traffic generator (ver. 2.0) and I have a problem. My setup is simple: a server with configuration: on 0:25 udp 0.0.0.0.4400 server at 1.1 wait and a client with configuration: on 0:25 udp 0.0.0.0.4300 127.0.0.1.4400 at 5 setup at 6 arrival exponential 0.01 0.0001 1 length 500 time 10 The problem is this, after the client ends and makes a connection tear down the server keeps running and waiting for new data. I know that this is because of the nature of UDP and the fact that 'recvfrom' in line 267 of the prot_dgram.c never returns 0. I've noticed that there is a time out (by default a very, very long timeout) but after which the log file isn't ended the way it should be. So when a use gengraph.pl a get an "Error: premature end of file" error! Is there a fix? thx a lot -- Andro From b_a_denny at yahoo.com Fri Jul 28 15:10:07 2006 From: b_a_denny at yahoo.com (Barbara Denny) Date: Fri, 28 Jul 2006 15:10:07 -0700 (PDT) Subject: [tg] Traffic Generator: UTP server question In-Reply-To: <44C9CF5D.4080007@ericsson.com> Message-ID: <20060728221007.62632.qmail@web30104.mail.mud.yahoo.com> hi, Hum....you might have found a bug. I've never waited for tg to "timeout" on the receive side of a udp stream. I'll need to look at that. I have noticed that the behavior of tg has changed slightly with linux. Sending a TERM or INT signal to the process should cause the process to die and the log to be written out. It doesn't do that and I can't see any "bug" in the software so I need to do some more debugging. (If anyone else has had problems with redirecting a signal to a new handler under linux, let me know. That appears to be the problem here). As a work around I suggest the following, use the -f switch (for flush) when you start your client so the data will not be buffered. Then manually kill the tg process on the receive side with a USR1 or kill signal after the send side is done. Hope this "solution" is satisfactory for you. barbara --- "Andro Galinovic (ZG/ETK/DR)" wrote: > Hi. > > I'm using your traffic generator (ver. 2.0) and > I have a problem. > My setup is simple: a server with configuration: > > on 0:25 udp 0.0.0.0.4400 server > at 1.1 wait > > and a client with configuration: > > on 0:25 udp 0.0.0.0.4300 127.0.0.1.4400 > at 5 setup > at 6 arrival exponential 0.01 0.0001 1 length 500 > time 10 > > > The problem is this, after the client ends and > makes a connection > tear down the server keeps running and waiting for > new data. I know that > this is because of the nature of UDP and the fact > that 'recvfrom' in > line 267 of the prot_dgram.c never returns 0. I've > noticed that there is > a time out (by default a very, very long timeout) > but after which the > log file isn't ended the way it should be. So when a > use gengraph.pl a > get an "Error: premature end of file" error! > Is there a fix? > > > thx a lot > > -- > > > Andro > > > > _______________________________________________ > tg mailing list > tg at postel.org > http://mailman.postel.org/mailman/listinfo/tg > From b_a_denny at yahoo.com Sat Jul 29 17:25:51 2006 From: b_a_denny at yahoo.com (Barbara Denny) Date: Sat, 29 Jul 2006 17:25:51 -0700 (PDT) Subject: [tg] Traffic Generator: UTP server question In-Reply-To: <20060728221007.62632.qmail@web30104.mail.mud.yahoo.com> Message-ID: <20060730002551.57680.qmail@web30103.mail.mud.yahoo.com> Hello Everyone, I found the "bug" handling the INT and TERM signals in the TG process. If someone needs the fix right away, let me know. Of course, I should have mentioned you can specify a time literal after the wait command in the receive side script. This will cause an automatic shutdown. You need to make sure you have left enough time for the send side to finish. If you don't, errors will be recorded in the send side log (errno 111). Andro, can you let me know how long it took for tg to shutdown on its own? barbara --- Barbara Denny wrote: > hi, > > Hum....you might have found a bug. I've never > waited > for tg to "timeout" on the receive side of a udp > stream. I'll need to look at that. > > I have noticed that the behavior of tg has changed > slightly with linux. Sending a TERM or INT signal > to the process should cause the process to die and > the log to be written out. It doesn't do that and > I can't see any "bug" in the software so I need to > do some more debugging. (If anyone else has had > problems with redirecting a signal to a new > handler under linux, let me know. That appears to > be the problem here). > > As a work around I suggest the following, use the > -f switch (for flush) when you start your client > so the data will not be buffered. Then manually > kill the tg process on the receive side with a > USR1 or kill signal after the send side is done. > > Hope this "solution" is satisfactory for you. > > barbara > > --- "Andro Galinovic (ZG/ETK/DR)" > wrote: > > > Hi. > > > > I'm using your traffic generator (ver. 2.0) > and > > I have a problem. > > My setup is simple: a server with configuration: > > > > on 0:25 udp 0.0.0.0.4400 server > > at 1.1 wait > > > > and a client with configuration: > > > > on 0:25 udp 0.0.0.0.4300 127.0.0.1.4400 > > at 5 setup > > at 6 arrival exponential 0.01 0.0001 1 length 500 > > time 10 > > > > > > The problem is this, after the client ends and > > makes a connection > > tear down the server keeps running and waiting for > > new data. I know that > > this is because of the nature of UDP and the fact > > that 'recvfrom' in > > line 267 of the prot_dgram.c never returns 0. I've > > noticed that there is > > a time out (by default a very, very long timeout) > > but after which the > > log file isn't ended the way it should be. So when > a > > use gengraph.pl a > > get an "Error: premature end of file" error! > > Is there a fix? > > > > > > thx a lot > > > > -- > > > > > > Andro > > > > > > > > _______________________________________________ > > tg mailing list > > tg at postel.org > > http://mailman.postel.org/mailman/listinfo/tg > > > > _______________________________________________ > tg mailing list > tg at postel.org > http://mailman.postel.org/mailman/listinfo/tg > From andro.galinovic at ericsson.com Mon Jul 31 01:00:23 2006 From: andro.galinovic at ericsson.com (Andro Galinovic (ZG/ETK/DR)) Date: Mon, 31 Jul 2006 10:00:23 +0200 Subject: [tg] Traffic Generator: UTP server question In-Reply-To: <20060728221007.62632.qmail@web30104.mail.mud.yahoo.com> References: <20060728221007.62632.qmail@web30104.mail.mud.yahoo.com> Message-ID: <44CDB897.4030402@ericsson.com> Hi Barbara. Hugues from info.fundp.ac.be also suggested "-f". As I said to Hugues "-f" works, but I still have to change the code and decrease the timeout (prot_dgram.c line 319): else { /* Nothing more to read right */ /* now. */ gettimeofday(endtout, (struct timezone *)NULL); endtout->tv_sec+=30; break; } and recompile the program which ends in multiple warnings and an error ( tg.y:271: error: conflicting types for 'malloc' ). But I can fix that. The error I mean, by commenting line 271 in the file tg.y ( //extern char *malloc(); ). Warnings (see attachment ) still remain but I suppose that's OK :) I just think that's inconvenient that the server doesn't stop when the client stops, because if a have a script that runs tg more then ones with the same configuration file (same address, port number,....) or I rerun that script, that it can be a problem. I suppose a "end" UDP message would do the trick. In my case manually kill the tg process isn't a option, everything has to be automatic. bye Andro Barbara Denny wrote: > hi, > > Hum....you might have found a bug. I've never waited > for tg to "timeout" on the receive side of a udp > stream. I'll need to look at that. > > I have noticed that the behavior of tg has changed > slightly with linux. Sending a TERM or INT signal > to the process should cause the process to die and > the log to be written out. It doesn't do that and > I can't see any "bug" in the software so I need to > do some more debugging. (If anyone else has had > problems with redirecting a signal to a new > handler under linux, let me know. That appears to > be the problem here). > > As a work around I suggest the following, use the > -f switch (for flush) when you start your client > so the data will not be buffered. Then manually > kill the tg process on the receive side with a > USR1 or kill signal after the send side is done. > > Hope this "solution" is satisfactory for you. > > barbara > -------------- next part -------------- A non-text attachment was scrubbed... Name: compile.log Type: text/x-log Size: 6574 bytes Desc: not available Url : http://mailman.postel.org/pipermail/tg/attachments/20060731/f898459a/compile.bin From andro.galinovic at ericsson.com Mon Jul 31 01:23:21 2006 From: andro.galinovic at ericsson.com (Andro Galinovic (ZG/ETK/DR)) Date: Mon, 31 Jul 2006 10:23:21 +0200 Subject: [tg] Traffic Generator: UTP server question In-Reply-To: <20060730002551.57680.qmail@web30103.mail.mud.yahoo.com> References: <20060730002551.57680.qmail@web30103.mail.mud.yahoo.com> Message-ID: <44CDBDF9.5020503@ericsson.com> Hi What do you meed "you can specify a time literal after the wait command in the receive side script"? If I have a receiver side script : on 0:25 udp 0.0.0.0.4400 server at 1.1 wait than tg enters wait state 1.1. s after the start time synchronization boundary, if I'm not mistaken. Can I specify and say "wait for x seconds and than die"? To answer your question ("how long it took for tg to shutdown on its own?") the answer is very long... in the line 1052 of the file tg.y the timeout is specified with a absolute time "cur_tg->stop_before.tv_sec = 0x7fffffff;" which represent some time in the year 2038. As I said in my previous e-mail I added two lines which make the timeout 30 seconds from the current time every time there's nothing more to read i.e. recvfrom returns < 0 and with errno == EWOULDBLOCK. That seems to fork fine, for now :) Andro Barbara Denny wrote: > Hello Everyone, > ... > > Of course, I should have mentioned you can > specify a time literal after the wait command > in the receive side script. This will cause > an automatic shutdown. You need to make sure > you have left enough time for the send side to > finish. If you don't, errors will be > recorded in the send side log (errno 111). > > Andro, can you let me know how long it took > for tg to shutdown on its own? > > barbara > From b_a_denny at yahoo.com Mon Jul 31 16:32:08 2006 From: b_a_denny at yahoo.com (Barbara Denny) Date: Mon, 31 Jul 2006 16:32:08 -0700 (PDT) Subject: [tg] Traffic Generator: UTP server question In-Reply-To: <44CDBDF9.5020503@ericsson.com> Message-ID: <20060731233208.57329.qmail@web30115.mail.mud.yahoo.com> Hi, Yes. You can say wait for so much time on the receive side and then the process will end. For example, at 1.1 wait 60 This causes tg to end 60 seconds after the time requested by the at action; i.e. about 61.1 seconds after the setup. (or 1:30 for one minute 30 seconds, etc). I just don't use it because I am constantly tweaking scripts as I test things so killing the process itself works well for me. >From your original message I did not realize you had modified tg to make it end. I looked at the code and saw the line you mentioned below so I didn't see how it could have exited on its own. barbara --- "Andro Galinovic (ZG/ETK/DR)" wrote: > Hi > > What do you meed "you can specify a time literal > after the wait command > in the receive side script"? > If I have a receiver side script : > on 0:25 udp 0.0.0.0.4400 server > at 1.1 wait > than tg enters wait state 1.1. s after the start > time synchronization > boundary, if I'm not mistaken. Can I specify and say > "wait for x seconds > and than die"? > > To answer your question ("how long it took for tg to > shutdown on its > own?") the answer is very long... in the line 1052 > of the file tg.y the > timeout is specified with a absolute time > "cur_tg->stop_before.tv_sec = > 0x7fffffff;" which represent some time in the year > 2038. As I said in my > previous e-mail I added two lines which make the > timeout 30 seconds from > the current time every time there's nothing more to > read i.e. recvfrom > returns < 0 and with errno == EWOULDBLOCK. > That seems to fork fine, for now :) > > > Andro > > > > Barbara Denny wrote: > > Hello Everyone, > > ... > > > > Of course, I should have mentioned you can > > specify a time literal after the wait command > > in the receive side script. This will cause > > an automatic shutdown. You need to make sure > > you have left enough time for the send side to > > finish. If you don't, errors will be > > recorded in the send side log (errno 111). > > > > Andro, can you let me know how long it took > > for tg to shutdown on its own? > > > > barbara > > >