Transfer is sparatic

[PiDD]

I am getting some unexpected results when doing a copy.  I really dont know if its from the copy pc or the lime server.  It will copy for a little while then stop for a bit and start up again?  almost like it is filling a buffer ... writing  .. and starting again.

Any ideas on what I could do to fix this?

[WannaTheater]

I am seeing something similar, but not captured with a performance meter.  In my case, the Windows "Time Remaining" bar while copying jumps around alot (starts at 11 minutes, jumps to 8, back to 11, 9, 10, 7, 10, etc...).  It would seem logical that this is related.

[PiDD]

Here are my NIC settings

eth0      Link encap:Ethernet  HWaddr 00:17:9A:7A:5E:74
          inet addr:10.0.0.108  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:9000  Metric:1
          RX packets:27941297 errors:0 dropped:0 overruns:21213 frame:0
          TX packets:15931327 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1593312931 (1.4 GiB)  TX bytes:1629273186 (1.5 GiB)
          Interrupt:20

[parsec]

Network performance jumping up and down, can also be caused by either switch or nic been set to full duplex and the counterpart not being able to cope with it, or set to half duplex.

Avoid full duplex, unless absolutely sure that it is handled correctly.

/Rene

[PiDD]

it looks like I am 1000 full duplex all around ... at least thats what the lights on the dlink switch says.

How can I verify that on the lime server?  ifconfig doesnt seem to show it.

What are overruns?  should I be concerned about them?  They increase during the times where traffic is actually moving in a file transfer. 

I didnt have these issues with v3?  Should I just go back?


edit:  found the ethtool eth0 command!

i am running 1000 full duplex...
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Current message level: 0x00000037 (55)
        Link detected: yes

[WannaTheater]

I only noticed the jumping around of "Time Remaining" with the upgrade to unRaid v4.0beta2.  Nothing on my network has changed since running unRaid 3.0.

[limetech]

The 'jumpiness' you see in the graph is typical for unRAID.  It's because the network is faster than write throughput on the server. 

The 'jumpiness' of "Time Remaining" is due to variations in transfer time when Windows samples the transfer rate. 

There are a number of 'tunables' in the linux kernel & unraid driver which can also affect this.  I'll be writing a 'Tuning Guide' article soon.

[PiDD]

Will this on/off of the network flow affect playback? 

[limetech]

Doesn't happen with reads.

[MortenSchmidt]

The 'jumpiness' you see in the graph is typical for unRAID.  It's because the network is faster than write throughput on the server. 

The 'jumpiness' of "Time Remaining" is due to variations in transfer time when Windows samples the transfer rate. 

There are a number of 'tunables' in the linux kernel & unraid driver which can also affect this.  I'll be writing a 'Tuning Guide' article soon.

Sorry to wake up an old thread - hope it is ok.

Did this 'Tuning Guide' ever materialize ?  I searched both forum and wiki without luck.