Hi folks,
I was (rightfully) questioned about using the term lower rate, I'll
attempt to clarify as that's incorrect.
What the hires_tick setting does is reduce the interval of when data is
sent. Same amount of data, just sent in smaller chunks, over a smaller
amount of time. While the following numbers are for illustration only,
a scenario where the server was trying to send 200 Mb each second, would
now send at 20 Mb every tenth of a second with hires_tick set.
The end-result is actually a *higher* effective rate since it's
sustainable and not filling up the switches buffer. Switches only have
a fixed amount of cache to buffer. So in the above scenario, if your
switch can only buffer 100 Mb, you're in trouble from the start because
you've sent more than it can handle at once. With hires_tick set, it
won't have to buffer since it's well within the switches capability to
buffer. When the buffer is overran, packet loss can occur, which makes
everything worse as things try to back-off and negotiate a rate where it
doesn't happen.
Flow control can theoretically help by telling the sender to wait, but
it's not always implemented/honored correctly from vendor to vendor, nor
is always enabled by default usually due to it not always
implemented/honored correctly ;)
A switch with a 1 Gb ingress and 100 Mb egress will always buffer,
hires_tick reduces the size of what it has to buffer. 100 Mb ingress to
100 Mb egress, no buffering. Thus my statement about enterprise
switches was misleading at best.
Regardless, hires_tick is an easy tunable doesn't require you to mess
with switches, clients, etc. Give it a try.
On 9/27/12 6:06 AM, Cj Cant wrote:
To follow up on this, I suffered the same problem myself. I found that
disabling flow control on the ports on the switch improved performance
dramatically
Hope this is useful
Cheers
Cj
On 27 Sep 2012, at 04:10, "Craig Bender" <craig.ben...@oracle.com> wrote:
Very few (enterprise) switches handle udp buffering well. This limits the rate
to prevent overrunning the switch. In essence, it's granting a lower rate. At
higher rate, switches tend to drop the udp stream. Ironically, the more
expensive the switch, the more apt this is bound to happen. Cheap switches
just forward stuff on, they never buffer.
On 9/26/12 7:50 PM, David Bullock wrote:
On 27 September 2012 11:30, Craig Bender <craig.ben...@oracle.com
<mailto:craig.ben...@oracle.com>> wrote:
Try adding
set hires_tick = 1
to /etc/system and reboot
Hi Craig, you seem to be referring to lore written up in section
18.11.4.1 of
http://docs.oracle.com/html/E22661_15/Troubleshooting-Performance.html
where it mentions "The X server is allowed to send at a certain specific
rate granted by the Sun Ray Client".
So, does setting the hires_tick on the server ultimately cause the Sun
Ray Client to 'grant' a higher rate? Or does it affect only the server
so that it delivers data in a smoother (less bursty) fashion ("fill,
drain, fill, drain" instead of "fill,fill,drain,drain" where the switch
can only take so many un-drained fills before dropping a packet)?
Assuming the latter, is it more preferable to have a switch which can
handle the buffering, or to set the hires timer?
thanks,
thanks,
David.
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
SunRay-Users@filibeto.org
http://www.filibeto.org/mailman/listinfo/sunray-users
