Στις 06/01/2014 01:12 μμ, ο/η rkwesk_ltsp έγραψε:
> To maximise the benefit of the clients all connecting with the server
> the
> following options (in order of better benefit before lesser) are:
>
> 1 - disable hardware flow control (if possible) on the server's
> gigabyte nic.
> 2 - disable hardw
On 2014-01-05 11:20, Ben Green wrote:
> Quoting "Luis A. Guzmán García" :
>
>>
>> So, bottom line.
>>
>> On a healthy LTSP network the data flow should be controlled/limited
>> so
>> it can perform better, taking advantage of the TPC/IP avoiding the
>> buffer jamming on the switch, server or clien
Quoting "Luis A. Guzmán García" :
>
> So, bottom line.
>
> On a healthy LTSP network the data flow should be controlled/limited so
> it can perform better, taking advantage of the TPC/IP avoiding the
> buffer jamming on the switch, server or clients.
>
> Right?
Yep. Providing an easy way to do th
El sáb, 04-01-2014 a las 08:14 +0200, Alkis Georgopoulos escribió:
> Στις 04/01/2014 01:36 πμ, ο/η rkwesk_ltsp έγραψε:
> > Or are you saying that when the disabling of hardware flow control is
> > not an option then one should limit the rate of the data?
>
>
> Yup.
So, bottom line.
On a healt
Alkis Georgopoulos wrote:
>Στις 04/01/2014 01:36 πμ, ο/η rkwesk_ltsp έγραψε:
>> Or are you saying that when the disabling of hardware flow control is
>
>> not an option then one should limit the rate of the data?
>
>
>Yup.
So,
Bottom line.
On a healty LTSP network is always preffered to limit
Στις 04/01/2014 01:36 πμ, ο/η rkwesk_ltsp έγραψε:
> Or are you saying that when the disabling of hardware flow control is
> not an option then one should limit the rate of the data?
Yup.
--
Rapidly troubleshoot problem
On 2014-01-03 18:08, Alkis Georgopoulos wrote:
> Στις 03/01/2014 02:35 μμ, ο/η Alkis Georgopoulos έγραψε:
>> I think that the best solution would be to limit the rate of the
>> data
>> that the server sends to the clients (X, NBD, SSHFS/NFS...) to e.g.
>> 90
>> Mbps per client at the TCP level, p
Στις 03/01/2014 02:35 μμ, ο/η Alkis Georgopoulos έγραψε:
> I think that the best solution would be to limit the rate of the data
> that the server sends to the clients (X, NBD, SSHFS/NFS...) to e.g. 90
> Mbps per client at the TCP level, probably using iptables and tc.
>
Yup, success! I verified
E Kogler wrote:
> My option would be to force the gigabitport to 100MBit :-)
> Edgar-
The TCP/IP protocol has flow control "built in." If the sender is sending
too fast, the receiver will tell it to slow down. There really is
I think the main question left is:
what can we do if Ethernet flow control *cannot* be disabled in either
the server NIC or the switch?
(e.g. many Realtek or Atheros -based NICs and switches don't have flow
control configurable).
I think that the best solution would be to limit the rate of the da
On 03.01.2014 12:24, E Kogler wrote:
> My option would be to force the gigabitport to 100MBit :-)
> Edgar
>
>
>
> The issue here is that the buffer on the switch fills from data from
> its giga port
> while data is more slowly released through its 100 Mbps ports. What is
> hoped is that
> with flow
My option would be to force the gigabitport to 100MBit :-)
Edgar--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects th
On 2014-01-02 14:11, E Kogler wrote:
> I don't think disabling flow-control is a good idea.
> Flow-control enables the two different ports (100 MBit and GigaBit)
> to
> communicate without loss of packets.
> Modern switches adapt the speed of their ports to the speed of the
> port connected.
> (i.
I don't think disabling flow-control is a good idea.Flow-control enables
the two different ports (100 MBit and GigaBit) to communicate without loss of
packets.Modern switches adapt the speed of their ports to the speed of the
port connected.(i.e you could even connect a 10 MBit Port )Or to be
p
On 2013-12-30 13:39, Jakob Unterwurzacher wrote:
> On 29.12.2013 01:21, rkwesk_ltsp wrote:
>>
>> As the switch's port to the client is also 100 Mps I think the
>> client's
>> 100mps nic cannot be overloaded
>> per se. However, a fellow member of this list, alkisg, has since
>> explained to me that
On 29.12.2013 01:21, rkwesk_ltsp wrote:
>
> As the switch's port to the client is also 100 Mps I think the client's
> 100mps nic cannot be overloaded
> per se. However, a fellow member of this list, alkisg, has since
> explained to me that the buffer on the
> switch will fill up since it is receivi
On 2013-12-28 22:18, Jakob Unterwurzacher wrote:
> On 28.12.2013 12:18, rkwesk_ltsp wrote:
>> I thought I had this figured out but I'd like to confirm:
>>
>> Configuration 1
>>
>> unmanaged switch w 1 giga port and 16 100 ports not connected
>> directly
>> w router
>> Server with two nics, one gig
On 28.12.2013 12:18, rkwesk_ltsp wrote:
> I thought I had this figured out but I'd like to confirm:
>
> Configuration 1
>
> unmanaged switch w 1 giga port and 16 100 ports not connected directly
> w router
> Server with two nics, one gigabit to giga port on switch and one 100
> bit to router direct
I thought I had this figured out but I'd like to confirm:
Configuration 1
unmanaged switch w 1 giga port and 16 100 ports not connected directly
w router
Server with two nics, one gigabit to giga port on switch and one 100
bit to router directly.
Clients, mixed thin and fat but all with 100 bit
19 matches
Mail list logo
