frame rate arecont Vision 3105

[rak313 0]

 

As for data rate, I was getting over 30 FPS reported in the screen footer with the AV3130 in LR but only with the video resolution setting at "half". The recorded rate was about 20FPS. My guess is I have some issue with my PC.

 

To me it makes no sense. LR server is just receiving the frames and writing to disk. If is can read 30 FPS (about 4 megabyte/sec) over a 100 Mbps link, it surely should be able to write that rate to disk (I did a disk write thruput test and got about 25-30 Mbyte/sec ).

 

Thanks for the input.

 

As posted earlier by "Roman", if you are using LR 1.7.1.x, try using TFTP instead of HTTP. I can confirm that using HTTP protocol in LR 1.7.1.x does up to 20 fps on the AV3130 night sensor @ full res, and TFTP (used in LR 1.6.x) does up to 32 fps in full res. Contact LuxRiot support for info on enabling TFTP option in LR 1.7.1... it's just a matter of adding one registry key value and re-doing the definition of the camera using TFTP.

 

I was confused by this. I was not sure how to do it in Roman's post. It sound like what you are saying, is there is a setting in windows registry I need to set.

 

Well at this point, I have not yet decided whether to buy LR yet, so I don't think calling support seems fair.

[thewireguys 3]

What Exposure settings are you using? Full view quality setting?

[Roman 0]

I was confused by this. I was not sure how to do it in Roman's post. It sound like what you are saying, is there is a setting in windows registry I need to set.

 

I did not post here an essential information on how to do this, but I sent to skane in response to email to support, so he shares his experience...

 

I need to explain this in more detail. The problem is that we are reluctant to share this widely because this unlocks functionality we are deprecating. The way it worked before (TFTP) it worked almost great, thought rarely was anyway a source of issues of a different kind.

 

As we are deprecating this old method, at this point we left an option to unlock old functionality but there is no promise to support it further. This means that at some point later we might remove it completely and move to HTTP access method. Users will probably need to manually reconfigure the affected cameras. This however is going to happen after Arecont Vision updates their HTTP interface and offer equal performance (fps) on it. Currently we are providing instructions on how to get back the functionality being deprecated on request.

 

rak313, I sent you PM on this. By the way, make sure to check if your camera has latest firmware on it and upgrade if necessary.

[thewireguys 3]

latest firmware for the 3105 is..... 65114

latest firmware for the 3130 is..... 64329

[robert 0]

I can bet if u remove FS 108 switch your speed will be better

had the same problem before

 

What about Linksys SRW208P? Is Linksys quality stuff?

 

http://www-id.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=ID%2FLayout&cid=1175229863180&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=6318086156B20

[robert 0]

I just got the AV3130 today, and is is a lot more sensitive than the AV3105. With Low light setting on "high quality" you can see quite well with the 0.5 lux lighting I have. But this has 200 ms exposure, and any motion is blured. So I will be adding an IR source.

 

Any feedback after adding IR illuminator? Did motion blur disappeared?

[thewireguys 3]

With proper IR lighting you should have no problem eliminating motion blur..... set the low light mode to speed or high speed if you have enough light. On the 3130 to can manually set the exposures from 1-10ms on the 3105 you can set it 1-80ms. Did you know Arecont cameras can do more then 60FPS?

[ak357 0]

With proper IR lighting you should have no problem eliminating motion blur..... set the low light mode to speed or high speed if you have enough light.

 

why bother with 3130 if u have enough light ?

[thewireguys 3]

With proper IR lighting you should have no problem eliminating motion blur..... set the low light mode to speed or high speed if you have enough light.

 

why bother with 3130 if u have enough light ?

 

I was talking about IR light sorry.

[rak313 0]

I just got the AV3130 today, and is is a lot more sensitive than the AV3105. With Low light setting on "high quality" you can see quite well with the 0.5 lux lighting I have. But this has 200 ms exposure, and any motion is blured. So I will be adding an IR source.

 

Any feedback after adding IR illuminator? Did motion blur disappeared?

 

I bought a axis IR light T90A21 IR-LED 50-100 DEG (Edit: rebadged raymax 50). Works great, extremely powerful - like a 500 W flood light, only 20Watts, cost $500. But: 1) focus is different than white light (I'm using 2 computar 8 mm 2/3 in lenses on the av3130). This is not really an issue as there are 2 imagers, so one can be focused for IR. 2) (really big issue) My wife won't let me install the IR light outside on the house. It's pretty small, and I'll eventually wear her down, but for now, I'm just experimenting.

Edited July 27, 2009 by Guest

[rak313 0]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

[thewireguys 3]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

 

 

Nice work

[DoorMan 0]

Lots of good info here, thanks for taking the time.

[thewireguys 3]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

 

I would like to see the results if you where using Areconts software.

[rak313 0]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

 

I would like to see the results if you where using Areconts software.

Tried it tonight, it uses TFTP with the host acknowledging each packet, and the results were:

 

with a 1280 by 1024 BW frame, with 43 by 2, 1486 packets =128 k bytes in 0.02803 seconds or 36 Mbits/sec (timing first packet to last ack, not time between frame requests).

 

Funny thing was, the sequence was full frame, half frame, full frame ... being transfered. I don't know what that was about. I had the recording disabled.

[thewireguys 3]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

 

I would like to see the results if you where using Areconts software.

Tried it tonight, it uses TFTP with the host acknowledging each packet, and the results were:

 

with a 1280 by 1024 BW frame, with 43 by 2, 1486 packets =128 k bytes in 0.02803 seconds or 36 Mbits/sec (timing first packet to last ack, not time between frame requests).

 

Funny thing was, the sequence was full frame, half frame, full frame ... being transfered. I don't know what that was about. I had the recording disabled.

 

I like what your doing. I have seen my frame rates on the 3105 to 13/14 at full res. Try setting the camera to D1 res and see how much bandwidth it uses. Could you help me with Wireshark and I can run the same test on my Linksys switch. See if we can duplicate your results.

[rak313 0]

Perhaps you will be interest in some technical info on LuxRiot in connection with Arecont Vision cameras.

 

First of all, the latest LuxRiot is here - http://blog.luxriot.com/tag/release If you have version 1.7.1 but the numbers under about box are not 1.7.1.20014, then it's worth upgrading anyway.

 

Arecont Vision camera are capable of sending video over two protocols, HTTP and TFTP. The latter was used since long ago in LuxRiot through Arecont Vision SDK and until the latest LuxRiot update where we switched to HTTP. Previously with these cameras TFTP based communication was faster and resulted in higher FPS rates, however presense of SDK between LuxRiot and the device put us in position where we are not fully in control of things. Recently, especially with introduction of H.264 models, Arecont improved HTTP interface so it's primary in LuxRiot. We no longer have issues related to use of SDK, but we assume HTTP interface of the camera is as fast as its TFTP interface (still a question esp. for 8xxx models!).

 

Those who upgrade from earlier versions of LuxRiot will have their configurations work through legacy TFTP without changes. Newly configured cameras receive HTTP interface. It is also possible to tweak software and allow adding new cameras to use old TFTP interface of a camera.

 

Hope this helps.

 

I spent the last 2 weeks with zoneminder (ZM). I used the same hardware as I use with LuxRiot (LR), just different Hard drive. Unplug one HDD with windows, plug in another will Linux. Makes comparison more fair (I was not writing to disk for most of my comparisons).

 

After nearly succeeding with ZM (frame rate too low 1/2 what I was getting with LR), I decided to go with LR (placed order today). My main complaint with LR was slow frame rate and somewhat variable record rate (plus I don't like $300 for 4 cameras when I'll likely only have 2).

 

After using wireshark on both windows and Linux with both the 3130's built in web page using firefox, and LR on windows, and ZM on linux, I've concluded a number of things.

 

The 3130 uses TCP for communication, which means its speed is a function of how fast the destination gets back to it with acknowledgments. The fastest rate I could get for 1 image fetch (using HTTP/1.1) was about 28 Mbps, which is a long way from the advertised "up to 55 Mbps". Yet this may be the fault of either my switch as "thewireguys" suggests, my motherboards Ethernet NIC, or the underlying TCP stack.

 

Using firefox on both linux and windows, I noticed vastly different performance. On windows, with a frame rate set to just 1 fps, and using wireshark, you could see all of the data was there for a 1280x1024 BW frame (130kbytes using the settings I had), in 45 milliseconds(~22 fps). But on linux, while it took the same time for most the data, the last acknowledge from the host to the camera took an additional 20-40 ms. I blame this on the TCP stack, but it might be something else.

 

The same was true when using LR and ZM. The HTTP commands to the 3130 were identical. The data transfer times were very similar except for the last acknowledgement from the host (on linux with ZM an additional 20-40 ms). This meant I could get around 24 fps using LR on a BW frame at 1280x1024. But only around 5 fps with ZM.

 

At any rate, I've ordered LR and will see it I can live with that. My reason for high frame rates is actually gone (I bought an IR led, so can use short exposure high SNR captures), so I will likely end up with about 5-10. I just want 1/60 sec shutter speed.

 

Now for the rant:

 

I do not believe TCP should be used for IP cameras. Rather, extremely simple UDP, with a fixed (programmable) frame rate. Power up the camera, program the IP address of the host, port number, frame rate, other parameters, save them on camera NVM. Then on power up, the camera and the camera spits out constant UDP datagrams with no user programming. They fall on the floor if you have no program listening. (Just like a traditional camera's video, if you don't plug it in).

 

User program simply opens a socket and starts reading. Header in UDP datagrams says what's in each datagram. (e.g. could define each UDP datagram to be 1 line of image (up to 20 kpixels/line of 3 byte each). Header would include camera settings, # rows, # cols, shutter speed, time tag, line number.

 

If your software could not keep up, just lower fps. You will not drop data on a small network (with proper network settings).

 

End of rant

 

I would like to see the results if you where using Areconts software.

Tried it tonight, it uses TFTP with the host acknowledging each packet, and the results were:

 

with a 1280 by 1024 BW frame, with 43 by 2, 1486 packets =128 k bytes in 0.02803 seconds or 36 Mbits/sec (timing first packet to last ack, not time between frame requests).

 

Funny thing was, the sequence was full frame, half frame, full frame ... being transfered. I don't know what that was about. I had the recording disabled.

 

I like what your doing. I have seen my frame rates on the 3105 to 13/14 at full res. Try setting the camera to D1 res and see how much bandwidth it uses. Could you help me with Wireshark and I can run the same test on my Linksys switch. See if we can duplicate your results.

 

Sure! You get wireshark from wireshark.org (Edit: fix link)

 

After install on windows:

1) double click on wireshark icon

2) hit "capture" (on top menu line) --> Interfaces (select the ip address of your host that is connected to the camera).

3) Select start.

 

Now with luxriot running (or a browser, or anything) you will be capturing all of the traffic on that interface.

 

After some period, hit Capture --> stop

 

Then you will have a window that shows one line for each message. Each line has:

 

line number, time (seconds), Source IP, Destination IP, protocol (e.g TCP), message summary. Clicking on a line reveals what data was in the message.

 

Thats about all I know. You can set filters to only look for certain traffic, etc. But that is more than I usually do. This tool is very good for debugging why a device does not seem to work, as you can see if anything is comming back from a request to the device.

[rak313 0]

 

... Try setting the camera to D1 res and see how much bandwidth it uses....

 

What resolution is that ? (maybe 720x480?)

[thewireguys 3]

 

... Try setting the camera to D1 res and see how much bandwidth it uses....

 

What resolution is that ? (maybe 720x480?)

 

Yes .... at that resolution you should get close to 60fps

[rak313 0]

 

... Try setting the camera to D1 res and see how much bandwidth it uses....

 

What resolution is that ? (maybe 720x480?)

 

Yes .... at that resolution you should get close to 60fps

 

I set to BW mode, using arecont vision software res = half (640 x 512) and got 33 fps (TFTP ).

 

Not sure where the limit is but I'm guessing my PCs NIC is slow in responding with the acc, but again not sure. I think (but can't remember) that I tried this without the netgear POE switch, directly to the PC via crossover cable and external 13.8V PS to the camera and got similar speeds.

 

So If you are getting near 60 fps, then i'm guessing it's my pc (which is pretty good, 1.87 GHz core2 dual core 6300 with 4 Gbyte ram and Nvidia GT 8600. Motherboard is ASUS P5B delux (intel 965chipset) with onboard dual gigEthernet NIC.

[thewireguys 3]

Sorry I didn't have time to focus the camera but I wanted to show you that I could get 60+ fps with a Arecont camera and there software. Once the camera is focused FPS should go up. I am using a Supermicro server, single quad core xeon, with 4 gigs of ram and I don't know if this makes a difference but I am RDP'd into the machine. Also I the camera is powered with POE from a linksys switch then a gigbit link to my main Zyxel gigbit switch where the server is plugged into.

 

800x600

 

 

400x300

 

[Tailbone215 0]

I am using a Supermicro server, single quad core xeon, with 4 gigs of ram and I don't know if this makes a difference but I am RDP'd into the machine.

 

Supermicro makes some top shelf gear. I've been building systems with their products for many years. I just got my SC743T-R760B case in yesterday so I'm ready to put together a new Supermicro Xeon box. A Xeon proc definitely makes easy work of processing video and boosting framerate.

[thewireguys 3]

I am using a Supermicro server, single quad core xeon, with 4 gigs of ram and I don't know if this makes a difference but I am RDP'd into the machine.

 

Supermicro makes some top shelf gear. I've been building systems with their products for many years. I just got my SC743T-R760B case in yesterday so I'm ready to put together a new Supermicro Xeon box. A Xeon proc definitely makes easy work of processing video and boosting framerate.

 

At a great price too. Think I paid 1400 for everything but the OS.