OK, the next thing would be to do something like the following:
whilst the "frozen" vic is running and "trying to receive DV", use "ps
aux" to find out the frozen vic's PID (process id); then
strace -pPID
This will give you the status of any system calls that vic may be
making at a time...
If the last message is "futex waiting" and that's it (when vic is on a
very little cpu usage) then see below :-)
Yeah, when it's not using much CPU it's either running through a bunch of gettimeofday and recvfrom calls or hanging on futex(0x88c16b8, FUTEX_WAIT, 2, NULL
On the sending machine it doesn't hang on anything.
Interesting :-) We did have an interesting issue with Ubuntu (and only
Ubuntu ;-) ... but we were only able to replicate it when starting vic
from AG (python environment) and we didn't have enough time to
determine what it was (python
2.5 vs 2.4, Ubuntu vs Fedora vs
Slackware, 64bit vs 32bit architecture, vic, etc.)
The problem was replicated with the old vic as well so I was leaning
towards thinking that it was a system-related issue...
The problem was two-fold:
a) either vic would be taking 100% of CPU and strace would indicate
"poll/select" calls being made all the time (e.g
. as if the file
descriptors that vic was using for socket i/o, etc. got messed up by
the hosting system);
I know the lack of 100% cpu usage means this probably isn't the case, but for what it's worth there were no polls or selects when I did a 30 second or so strace.
b) or vic would be taking virtually no CPU and strace would show
"futex waiting" messages...
Sometimes "b" would come after "a"... (as if, eventually, reading from
the wrong file descriptor got to a "dead lock").
The only system that it was happening (from my shaky memory banks :-)
was 64bit Ubuntu Feisty Fawn (kernel 2.6.20) running python 2.5...
By the way - what Linux distro is running on the sending machine?
Same as the receiver (these are both 32bit by the way), which makes me think that the futex hanging thing is due to the worse video hardware somehow.
233.45.67.88/23456
with TTL 16 (I may need to increase it - but see how it goes :-)
You might want to turn the ttl up, I didn't see any streams on there when I checked Friday afternoon.
Just checking 1 more thing :-)
In the above example, I was meaning to redirect standard AND error
outputs of vic (hence 2>&1)... but this would depend on the shell you
are running, so perhaps doing
script
./vic YOUR-IP/PORT
then CTRL-D after a few seconds (in the terminal) - this should
generate a typescript file which will automatically include standard
error output... - otherwise, the leonlog2 file may have some missing
info...
When I do that, there's no error output in the file, just the standard out that I always see on the terminal.
One auxiliary thing: what is the display depth of your Xorg (it is
indicated as being defaulted to 24bpp in your xorg) - but just to make
sure that it is what being used at vic's runtime... (currently we only
support hi and true color resolutions)...
Yeah, Xorg is running at 24-bit.
--Andrew