Slow transmission over NFS

I have OMV Kralizec installed, been running fine as a new install post hardware upgrade a few weeks ago... But something has happened within the past week, copying files over NFS is taking forever for some reason. Watching videos via Plex is mostly ok, very few hiccups so I doubt it's a network hardware issue. But copying just 2.5gb from my Ubuntu workstation to an NFS mapped drive is taking nearly an hour... and it works only in short bursts of about 10 seconds with several minutes of it just waiting before a short burst of activity... Rebooting has not helped. All shares are setup as "rw,subtree_check,secure,no_root_squash" and they all mount fine locally, they just transfer data really slowly. Even getting a directory listing in Nautilus can take a few minutes. Any ideas what's going on and how to fix it?

Ubuntu 14.04 over a standard 10/100 network.
I'm mounting from the FSTAB with these
192.168.0.11:/MaxSea /mnt/MaxSea nfs4 nfsvers=4,auto 0 0
192.168.0.11:/TV_Shows /mnt/TVShows nfs4 nfsvers=4,auto 0 0
192.168.0.11:/Anime /mnt/Anime nfs4 nfsvers=4,auto 0 0

When I mount the shares manually it looks like this:
sudo mount -v /mnt/MaxSea/
getting a result of
mount.nfs4: timeout set for Tue Mar 17 13:51:26 2015
mount.nfs4: trying text-based options 'nfsvers=4,addr=192.168.0.11,clientaddr=192.168.0.168'

ifconfig for eth1 is
eth1 Link encap:Ethernet HWaddr fc:aa:14:85:50:4e
inet addr:192.168.0.168 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::feaa:14ff:fe85:504e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1632204 errors:0 dropped:0 overruns:0 frame:0
TX packets:2383743 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:423672150 (423.6 MB) TX bytes:2793428704 (2.7 GB)

ifconfig for eth0 on the OMV server is
eth0 Link encap:Ethernet HWaddr 50:e5:49:d6:ad:e3
inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5390120 errors:0 dropped:0 overruns:0 frame:0
TX packets:3712280 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:6814810302 (6.3 GiB) TX bytes:1576514858 (1.4 GiB)
Interrupt:41

Need anything else?

I added async and remounted the shares. It doesn't seem to be making any difference. Copying a folder that is less than a gig in size is still acting the same as I described above

I don't have Samba configured and running since I don't have any Windows machines myself, so there's not much of a need... but I'll go set it up and test it next. In the mean time, here's ethtool eth0 output

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes

Samba configured to one share, mapped and copying files over just fine with no delays or hang time.

It's a Realtek 8111E chip (10/100/1000 Mbit). Yeah, I was wondering why the Samba file transfer was going at a mega a second, but that's still faster than how it was behaving over NFS, where it copies data for about 10 seconds hangs for five or ten minutes and then copies for another 10 seconds... I'm guessing it's using an older driver. When that motherboard was in my workstation for the past couple of years I had to manually upgrade the driver to a different one up until a year ago, when Ubuntu seems to have fixed the issue... I assumed it was fix more or less universally. Even though the network speed is so slow, it's still able to simultaneously stream 2 different tv shows via Plex without any issues... But file transfers over NFS is not happening smoothly even without any other traffic on the network to the NAS.

Yeah, it was a bad network cable. Thanks guys.

It would seem that the declaration of victory was premature... It's still doing the same thing... just in larger bursts. Instead of stopping every 80mb or so, it stops around every 800MB

Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yesSettings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes

Ubuntu 14.4 LTS for my workstation has ethtool -i eth1 output of
driver: r8169
version: 2.3LK-NAPI
firmware-version: rtl8168g-2_0.0.1 02/06/13
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

The OMV Kralizec server reports for ethtool -i eth0
driver: atl1c
version: 1.0.1.0-NAPI
firmware-version: N/A
bus-info: 0000:02:00.0
supports-statistics: no
supports-test: no
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

Sorry for the delay... My 3D Printer kit came in and I've been focusing solely on building it for the past 10+ hours.

The motherboard in both the NAS and my workstation are the same, just different versions... Gigabyte 78LMT S2P rev 4 (I think the rev is right) on the OMV box and 78LMT USB3 on my workstation. That said they look very very different from each other. lol

Anyways.. Here's what you asked for:

02:00.0 Ethernet controller: Atheros Communications Inc. AR8151 v2.0 Gigabit Ethernet (rev c0)
Subsystem: Giga-byte Technology Device e000
Flags: bus master, fast devsel, latency 0, IRQ 41
Memory at fddc0000 (64-bit, non-prefetchable) [size=256K]
I/O ports at df00 [size=128]
Capabilities: [40] Power Management version 3
Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [6c] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] Device Serial Number ff-d6-ad-e3-50-e5-49-ff
Kernel driver in use: atl1c

I'm at a stopping point with my stuff and need sleep. I'll respond later this afternoon after I get some shuteye. Have a great one and thanks for all your help so far.

Yeah, I use to encounter that issue a few years back... but if that were taking effect the NAS wouldn't be on the network at all.... literally the traffic would be a complete standstill on all services with no ups and downs. I believe they fixed that issue a year ago, because when this mobo was my workstation that was the time I didn't have to manually install the network adapters... they just worked. I have lots of network traffic successfully in and out of the server. SAMBA is steadily copying files over at a normal speed now... it's just not ideal in my opinion, I'd rather have NFS working.

And just to satisfy you, I too tried several ways to instal the ALX driver, but none would work. Additionally I don't have any spare network cards right now.