Cisco Proximity delay while presenting

[espereir]

Hi team,

Does anyone knows what is the expected delay while sharing content through proximity? we have some videoconference rooms with this feature enabled and the delay is unbearable.

Regards,

espereir

[Henrik Bakken]

Hi espereir,

I usually see latency of less than half a second from content changes on my laptop screen to I see the rendered result on the video system.

What times do you observe in the rooms where it's unbearable?

If we have very slow network throughput between laptop and endpoint, this would increase the latency. We transfer about 3-400 kB per slide, so at eg 1 Mbps available throughput, you would increase the transfer time with 2-3 sec!

Best regards,
Henrik

[espereir]

Hi Henrik,

Thank you for your reply, we ended up connecting the codec to the same switch and the same VLAN as the access point that we are using, so there is no routing delay nor queueing delay; additionally we changed the mode on the TV to gaming and we noticed that the delay is huge on the projector and not on the TV, so I wanted to know the average delay so we can troubleshoot the issue.

The delay we have is around 3 seconds, we managed to lower it on the TV today; we also noticed that there some stuff in the way between the projector and the codec; there is a black box connected between the projector and the SX20, that downscales the image of the projector so it fits the projector screen;  there is also a Cat5 balun that  transforms the HDMI to cat5 and I think that those two boxes are adding up some milliseconds.

This is how it is connected:

SX20 HDMI --> HDMI balun CAT5 --> CAT5 balun HDMI  --> downscaler box --> Projector

As mentioned before, we placed the SX20 in the Wireless VLAN and we made sure that both the AP on that room and the codec are on the same switch so the processing and queueing delays were out of the picture, the building have Gigabit 2960X stack switches on each floor, each stack is connected to the core switches (4500X L3) through a 40 GB Etherchannel.

So, if it is not a matter of processing and queueing the only things that we have to check are the transmission delay (check if the WLAN is degraded by some noise or interference), or the stuff that is connected between the codec and projector.

Any thoughts on this matter are really appreciated.

Thanks and best regards,

espereir

[Zachariah Stewart]

Hi ,

      I am currently experiencing a similar delay issue on my VC units with proximity wireless content sharing.

     Do you have any information in regards to how you managed to lower the delay on the TV's? As we only have TVs and not projectors.

Did you find a definitive solution at all?

Any help would be appreciated.

regards,

Zack

[Henrik Bakken]

Hi Zack,
I just replied (to a pretty old post, sorry) from espereir above - it higlights some of the limitations with the current architecture. In it's current form, it will not be usable for using a mouse to aim at buttons/targets on screen, only looking at the presentation screen. For that, latency is too high and frame rate to low.

In regards to limiting delay that a screen adds (can be in order of several hundred ms), the best bet is usually to get it into some "game mode" or "laptop mode", by-passing the optimizations used for optimizing TV signals. There is unfortunately no one-to-rule-them-all-solution, so Google is required :)

Best of luck,
-Henrik

[bbcresearch]

We experience 15-20 seconds delay between mac proximity client and SX20 which makes it basically unusable.

Very frustrating as it is a neat feature but can't really roll out to users in this state sadly.

Any advice welcome,

Jon.

[bbcresearch]

I note that the application does not respect http proxy settings so is unable to look for updates, and also the log file is full of

HTTPCode=0 method="receivers/simple" errorString="Failed to connect to cisco.splunkcloud.com port 8089: Network is unreachable" curlCode=7 requestSize=92645 responseSize=0 elapsedTime=0.326576 requestUrl="https://cisco.splunkcloud.com:8089/services/receivers/simple?.." retryCount=1

Hopefully the timeout in that connection is not holding up transfer of images to the video endpoint? The frequency that these errors appear in the log would make that a possibility.

Jon.

[mneergaa]

These logging related statements should not affect the connection to the codec.

[mneergaa]

Look in the log, find the lines with method="upload_present"  – these are the presentation uploads. If they have a high elapsedTime, especially if the timing has a high variance, I would suspect network issues. Feel free to upload a log here if you want us to take a quick look. Make sure to remove any content you do not wish to share, e.g. meeting room name and SIP URI may be logged.

[espereir]

We changed the projector and the delay was significantly decreased; we are about 2 frames per second, so 30 ms between content changes, however it is really difficult to track the mouse movement while reviewing a spreadsheet; so my question now is if there is a way to increase the amount of fps that are sent to the codec? Or are there any plans to add those parameters in future CE releases?

Thanks and best regards,

--espereir

[Henrik Bakken]

Hi Espereir,
great to hear you managed to reduce delay (it should not be the 3 seconds you experienced initially).

However - since we do send individual JPEG images over the wire, the full delay chain for a single frame is;

 grab > encode > transmit (entire file; ~3-400 kB) > decode on endpoint > render

Grabbing of the next frame will only happen when the Proximity client gets a confirmation that the codec is done processing the first. Eg; we are very dependent on network speed and processing on the endpoint.

Based on this architecture, we will not get neither very short latency, fast framerate or high bandwidth effeciency. We are considering solving this in a better way sending the presentation data as a video stream. This requires significant architectural changes, though, so we have not yet commited on a timeline. Rest assured - we're as eager as you are to solve this :)

Br
Henrik

[espereir]

Any troubleshooting tips besides sniffing the network? Any suggestions on how to measure the delay?

Thanks and best regards,

--espereir