VMware Horizon Community
davmware
Enthusiast
Enthusiast

Decrease in Bandwidth PCoIP View 5.0.1

Hi,

I am trobleshooting a VM on which PCoIP Server logs is showing a lot of decrease in bandwidth events. In a LAN environment I have seen the limit around 2500 KBps but in this case (WAN) the bandwidth available goes from initial 1700 and goes down and down till it reaches 14 KBps. It is really low. We got the remote user's internet connectivity checked out and it came clean (well the internet company will not admit an issue that easily experience says).

Checking the host level network logs and there are no drops found. Can there be anything in the infrastructure that can cause this behaviour or would it be solely client's connection to the infrastructure?

Excerpt from the PCoIP Server Logs:

08/07/2012, 12:17:14.351> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  30.3707 new =  26.0429
08/07/2012, 12:17:14.664> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  31.1597 new =  26.7195
08/07/2012, 12:17:15.132> LVL:2 RC:   0             IPC :NAK LOSS   for disp 0 fsp  5 f_seq   0,158 s_seq 227. (s   2 ar 0 mra 0) recode from reference
08/07/2012, 12:17:15.460> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  30.2529 new =  25.9419
08/07/2012, 12:17:15.773> LVL:2 RC:   0             IPC :Frame encode took 1599ms so far. Dropping down the quality to index 4.
08/07/2012, 12:17:15.976> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  29.0583 new =  24.9175
08/07/2012, 12:17:16.023> LVL:2 RC:   0             IPC :Encoder clearing recode for disp 0 fsp  5 f_seq   0,159 s_seq   7
08/07/2012, 12:17:17.773> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  30.1285 new =  25.8352
08/07/2012, 12:17:18.133> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  30.9112 new =  26.5063
08/07/2012, 12:17:18.289> LVL:2 RC:   0             IPC :NAK LOSS   for disp 0 fsp 11 f_seq   0, 76 s_seq 254. (s   2 ar 0 mra 0) recode from reference
08/07/2012, 12:17:18.289> LVL:2 RC:   0             IPC :NAK LOSS   for disp 0 fsp 12 f_seq   0,120 s_seq 255. (s   2 ar 0 mra 0) recode from reference
08/07/2012, 12:17:18.289> LVL:2 RC:   0             IPC :NAK LOSS   for disp 0 fsp 13 f_seq   0,165 s_seq   0. (s   2 ar 0 mra 0) recode from reference
08/07/2012, 12:17:18.726> LVL:2 RC:   0             IPC :Encoder clearing recode for disp 0 fsp 11 f_seq   0, 80 s_seq   2
08/07/2012, 12:17:18.742> LVL:2 RC:   0             IPC :Encoder clearing recode for disp 0 fsp 12 f_seq   0,121 s_seq  44
08/07/2012, 12:17:18.742> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  30.2609 new =  25.9487
08/07/2012, 12:17:18.758> LVL:2 RC:   0             IPC :Encoder clearing recode for disp 0 fsp 13 f_seq   0,167 s_seq   4
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log: cur_s   0 max_s  30 bwc 0.08 bwt 0.22, decode rate est (MBit/sec) - 4.75
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log: Disp_0:SoftPCoIP, Disp_1:Disabled, Disp_2:Disabled, Disp_3:Disabled
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log (SoftIPC): tbl 4 fps 0.70
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log (SoftIPC):  delta bits encoded: 1881167, delta build bits encoded: 693017.
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log (SoftIPC):  bits/pixel - 2.32, bits/sec - 62746.91, MPix/sec - 0.03
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log (Tera2800IPC): fps 0.00
08/07/2012, 12:17:19.445> LVL:2 RC:   0        MGMT_IMG :log (Tera2800IPC): bits/sec - 0.00, MPix/sec - 0.00, rx_pdu/sec - 0.0, tx_pdu/sec - 0.0
08/07/2012, 12:17:21.945> LVL:2 RC:   0 MGMT_PCOIP_DATA :Tx thread info: round trip time (ms) = 133, variance = 9, rto = 242
08/07/2012, 12:17:22.883> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  32.9579 new =  31.6528
08/07/2012, 12:17:32.555> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  38.3560 new =  36.8371
08/07/2012, 12:17:32.712> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  36.8371 new =  31.5878
08/07/2012, 12:17:33.618> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  32.1991 new =  27.6108
08/07/2012, 12:17:33.618> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (floor) old =  23.3264 new =  16.3284, tx =  22.8467, avg=15
08/07/2012, 12:17:33.805> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (loss) old =  27.6108 new =  23.6762
08/07/2012, 12:17:33.805> LVL:1 RC:   0 MGMT_PCOIP_DATA :BW: Decrease (floor) old =  20.6337 new =  14.4436, tx =  23.7903, avg=16
08/07/2012, 12:17:33.837> LVL:2 RC:   0             IPC :NAK LOSS   for disp 0 fsp 10 f_seq   0, 84 s_seq 172. (s   2 ar 0 mra 0) recode from reference

-DA

Reply
0 Kudos
3 Replies
Linjo
Leadership
Leadership

This looks like some kind of QOS-policy that degrades UDP traffic.

You could set the bandwith floor to 500k or something so PCoIP will not try to go under that.

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
davmware
Enthusiast
Enthusiast

Thanks.

If we set the floor value, won't PCoIP autotuning capabilities be disabled? I am just trying to weight the options and their effect.

Reply
0 Kudos
Linjo
Leadership
Leadership

Well it will not be disabled but will not try to lower the bandwith under 500k, with that said the bandwith can still be under 500k but the user experience will probably suffer if it comes to that.

If you set this and it works well then its probably some network qos going on.

If you want to dig deeper inte PCoIP tweeking then the PCoIP Log Viewe is a valuable tool:

http://mindfluxinc.net/

// Linjo

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos