Yeah its like solving a crime!

If you think it may be network topography related that's also pretty easy to check. Large file movements using scp or 1500 byte flood pings from/to multiple concurrent hosts are a good method. Looking at the ifconfig display of the Linux boxes for errors can help too. In the early days of FDX there were some RFC disagreements of a sort. I remember having to force a few Compaq DL380 servers into HDX to resolve overrun issues on FDX. At the time too we had some 24 port Cisco 10/100 switches that only had an aggregate throughout of 300Mbits/sec! That trapped us more than once.

ie have a look at the switch specs just in case..

I'd dispute that 5.8MB/s wouldn't be saturating a 100MBit/sec Ethernet. I'll admit I haven't done any test recently, but that's mighty close to the magic 60% I use to use for network scaling 10 years ago. Lots of overhead to contend with. Whatever the case its easy to check with large file transfers to /dev/null etc. It gets really upsetting when you find your 100MBit/sec link isn't!

Greyscale jpgs I think compress better than colour, so they are smaller. My daytime single image size for the 1280x1024 at 80% is about 340KB whereas the IR lit night monochrome scene runs about 200K. That diff can have a large network impact.

Okay, leave you with it!

Cheers Bob

On 25/11/12 05:46, Jason Sauders wrote:
Hm, this is giving me some food for thought. After some additional testing it seems as if the bottleneck has occurred at both the network level and the camera level (at least, I think so). I put my 10/100 switch back and sure enough things were acting slow as they did before when I had multiple streams going on. Once on the gigabit line, things worked significantly better. I'm not sure if it's just the switch processing the data faster that helps or what, because the cameras do indeed have 10/100 ports on them. I did the jpg test and most images were in the 180 Kb area. Using 200 as a "worst case scenario" type of number, that comes out to 5.8 MB/s. That's at 1280x800 with 30 fps. The max possible for 10/100 lines is 12.5 MB/s, so 5.8 MB/s isn't hitting the 10/100 throttle at the camera level. However, perhaps my 10/100 switch having to process two cameras @ 5.8 MB/s consistently was enough to make the Netgear switch seem significantly slower with the teleporting, whereas the Dell (gigabit) worked much better. During my typical Motion usage, I do not capture snapshots. I simply capture 1 fps timelapses and avi files of the motion recorded, typically at 15 fps (but this 30 fps kick I'm on is really just for comparisons)

That said, I'm finding some strange things here. Last night I had both cameras running at 30 fps with webcam_maxrate 30 fps and I was streaming both of them simultaneously. There was zero skipping, absolutely zero. When cars would go flying by I would see absolutely zero skipping, both live when I was viewing it and even when I viewed the .avi's back on the server. Today, things are much different and it seems as if skipping is much more apparent. Now granted, I was tinkering around with some network stuff Perhaps that's the difference in quality of night vision black/white/and I assume lesser quality feeds versus day time where there's much more going on. Hard to say. 

Today I decided to remove Motion from the picture, so I disabled the service and just began streaming the direct mjpg url. There's three fields to work with when it comes to mjpg streams. Resolution, Framerate, and Quality. We're working with 1280x800/30 fps here, but the quality I have set to "excellent." I've been doing some comparisons of that excellent field. Available options are Medium, Standard, Good, Detailed, Excellent. At 30 fps with the 1280x800 resolution, excellent has skipping. Again, no Motion here - just a direct mjpg url streaming over cat6 lines and a gigabit switch. If I clock it back to 30 fps/good (instead of excellent), I see no skipping at all. If I swap them around and do 20 fps/excellent, it's the same deal. I guess utilizing excellent with the highest fps possible is what's tanking it.

Networking wise, I've been doing some tracking based on the different settings possible. Even if I'm using excellent, 30fps, 1280x800, I'm still barely hitting a consistent 5.0 MB/s. It's more like an average of 4.3 MB/s with an occasional bump to the 4.9 area. Even on 10/100, your max throughput given that there's zero noise etc is 12.5 MB/s, which I'm still far off from even when you take some headroom into consideration. I'm really beginning to lean towards the camera's processor being able to crunch the "excellent" video quality with 30 fps is where the root cause is. Couple that in with Motion and you have quite a few cooks in the kitchen who might be responsible. Given the circumstances, it doesn't look like Motion really played a key role at all in this.

I think what I'm going to do is just throttle the fps settings back, as that tends to be a "best of both worlds" type of situation. Even at 15 fps, I'm still getting fifteen shots a second - that should be more than enough in case Mr. Burglar decides he wants my grill.

Thanks for the discussion Bob. This got some gears turning!