glenn zamorski

Does anyone have any "official" (from MS that is) numbers for the bandwidth
used per session on an RDP session?

For instance if you have 40 people coming in through a WAN link what is
average Kbps each session uses. You could then generate the minimum size pipe
you need. Assuming RDP only - no data transfer.

I've hunted around MS and the Net but I haven't found any definitive
information. I'm trying to save my self a day of sniffer tracing!

Glenn Zamorski
MCSE

oj

The answer to how much bandwidth RDP uses is effectively "as much as it can
get". Most applications will take as much bandwidth as they possibly can.
In general, more bandwidth is always better, although there are limits to
what's practical. This is where QoS can come in handy to throttle the amont
of bandwidth WTS sessions can use.

Fundamentally, the RDP protocol is simple data streams that are sent
between the client and the server. If the amount of data moving through the
stream is less than the amount of bandwidth that's available, then
everything will be fine and you'll have no problem. However, if the RDP
protocol tries to use more bandwidth than is available, then we see latency
and slow performance. We can limit the amount of bandwidth that is
requested by the session by disabling theme support and redicted printers
and drives, however it is impossible to say how much bandwidth it needs.

There are statements floating around on the Internet that say things like
"Citrix ICA uses 15kbps" (or 20k or 30k or whatever). There is one thing
that's critical to understand about these statements: Any statement about
ICA or RDP bandwidth usage simply refers to an average over some period of
time. The longer the time period, the more accurate the average.

In real life, ICA and RDP are extremely "bursty." If you don't touch the
mouse and nothing's happening on the screen, no data will cross the network
(except for the occasional keep alive packet). However, if you launch a new
program where the screen is continually updated, then the bandwidth
requirement shoots up.

glenn zamorski

Does anyone have any "official" (from MS that is) numbers for the bandwidth
used per session on an RDP session?

For instance if you have 40 people coming in through a WAN link what is
average Kbps each session uses. You could then generate the minimum size pipe
you need. Assuming RDP only - no data transfer.

I've hunted around MS and the Net but I haven't found any definitive
information. I'm trying to save my self a day of sniffer tracing!

Glenn Zamorski
MCSE

oj

The answer to how much bandwidth RDP uses is effectively "as much as it can
get". Most applications will take as much bandwidth as they possibly can.
In general, more bandwidth is always better, although there are limits to
what's practical. This is where QoS can come in handy to throttle the amont
of bandwidth WTS sessions can use.

Fundamentally, the RDP protocol is simple data streams that are sent
between the client and the server. If the amount of data moving through the
stream is less than the amount of bandwidth that's available, then
everything will be fine and you'll have no problem. However, if the RDP
protocol tries to use more bandwidth than is available, then we see latency
and slow performance. We can limit the amount of bandwidth that is
requested by the session by disabling theme support and redicted printers
and drives, however it is impossible to say how much bandwidth it needs.

There are statements floating around on the Internet that say things like
"Citrix ICA uses 15kbps" (or 20k or 30k or whatever). There is one thing
that's critical to understand about these statements: Any statement about
ICA or RDP bandwidth usage simply refers to an average over some period of
time. The longer the time period, the more accurate the average.

In real life, ICA and RDP are extremely "bursty." If you don't touch the
mouse and nothing's happening on the screen, no data will cross the network
(except for the occasional keep alive packet). However, if you launch a new
program where the screen is continually updated, then the bandwidth
requirement shoots up.

glenn zamorski

Does anyone have any "official" (from MS that is) numbers for the bandwidth
used per session on an RDP session?

For instance if you have 40 people coming in through a WAN link what is
average Kbps each session uses. You could then generate the minimum size pipe
you need. Assuming RDP only - no data transfer.

I've hunted around MS and the Net but I haven't found any definitive
information. I'm trying to save my self a day of sniffer tracing!

Glenn Zamorski
MCSE

oj

The answer to how much bandwidth RDP uses is effectively "as much as it can
get". Most applications will take as much bandwidth as they possibly can.
In general, more bandwidth is always better, although there are limits to
what's practical. This is where QoS can come in handy to throttle the amont
of bandwidth WTS sessions can use.

Fundamentally, the RDP protocol is simple data streams that are sent
between the client and the server. If the amount of data moving through the
stream is less than the amount of bandwidth that's available, then
everything will be fine and you'll have no problem. However, if the RDP
protocol tries to use more bandwidth than is available, then we see latency
and slow performance. We can limit the amount of bandwidth that is
requested by the session by disabling theme support and redicted printers
and drives, however it is impossible to say how much bandwidth it needs.

There are statements floating around on the Internet that say things like
"Citrix ICA uses 15kbps" (or 20k or 30k or whatever). There is one thing
that's critical to understand about these statements: Any statement about
ICA or RDP bandwidth usage simply refers to an average over some period of
time. The longer the time period, the more accurate the average.

In real life, ICA and RDP are extremely "bursty." If you don't touch the
mouse and nothing's happening on the screen, no data will cross the network
(except for the occasional keep alive packet). However, if you launch a new
program where the screen is continually updated, then the bandwidth
requirement shoots up.