Hello Chris,

Thanks for your post.

The patch for this as a permanent configuration is trivially easy. In /usr/clearos/apps/network/libraries/Iface.php, somewhere between line 1646 and 1668, add a line:

        $info['LINUX_PLUGIN'] = '/usr/lib64/pppd/2.4.5/rp-pppoe.so';

My section looks like:

        $info = array();

        $info['DEVICE'] = $eth;

        $info['TYPE'] = self::TYPE_PPPOE;

        $info['USERCTL'] = 'no';

        $info['BOOTPROTO'] = 'dialup';

        $info['NAME'] = 'DSL' . $eth;

        $info['ONBOOT'] = 'yes';

        $info['PIDFILE'] = '/var/run/pppoe-' . $eth . '.pid';

        $info['FIREWALL'] = 'NONE';

        $info['PING'] = '.';

        $info['PPPOE_TIMEOUT'] = '80';

        $info['LCP_FAILURE'] = '5';

        $info['LCP_INTERVAL'] = '20';

        $info['CLAMPMSS'] = '1412';

        $info['CONNECT_POLL'] = '6';

        $info['CONNECT_TIMEOUT'] = '80';

        $info['DEFROUTE'] = 'yes';

        $info['SYNCHRONOUS'] = 'no';

        $info['ETH'] = $physdev;

        $info['PROVIDER'] = 'DSL' . $eth;

        $info['PEERDNS'] = ($peerdns) ? 'yes' : 'no';

        $info['USER'] = $username;

        $info['LINUX_PLUGIN'] = '/usr/lib64/pppd/2.4.5/rp-pppoe.so';



        if (!empty($mtu))

            $info['MTU'] = $mtu;

You also need the firewall rule, but that should also be a one line patch if you use a sledgehammer and apply it all the time (which is safe as it only targets a ppp interface). If you need to detect a configured ppp interface it becomes more complicated.

The problem is this is a big change in PPPoE configuration and hence there is a lot of nervousness about breaking customer systems, especially as only one of the devs had a PPPoE line at the time of the thread. He has moved on, but in Feb I switched to PPPoE so I have been using it since then, but my line is only 40mbps down. If we could get more of the user base to trial it, we could get some confidence and, perhaps, switch. Perhaps we should try pushing it to the Community for a while, but there is a risk of a lot of disgruntled users if it does not work as expected.

Note that with kernel mode PPPoE, the MTU setting does nothing, which is why the firewall rule is needed. One possible issue is https sites breaking without the correct MTU, but I have not been seeing this so I am fairly confident.

Also worth noting is the synchronous and clampmss lines do nothing and other lines may become redundant as well.

Hi all,

Since this thread kept coming up every time I googled for a fix for my pppoe slow speed issue, I thought I would share the steps I took to fix it on mine.

I had the similar symptoms as the OP - pppoe works fine using a generic router/modem type thing at near the full speed of my ISP connection (Fibre to the premise, theoretical link at 100mbps, I could generally get 95mbps or so from speedtest.net), but under ClearOS (running on a celeron intel NUC with a usb gigabit ethernet dongle as the second NIC) it was only getting around 50mbps.

Using the hints in here and in the linked bug report - https://tracker.clearos.com/view.php?id=20251 - I managed to get back to ~95mbps. I am not exactly sure which commands were needed, or which will survive modifying anything in the webgui or a reboot, but.... for now, it's working so I am happy.

In the webgui, open the marketplace and install "custom firewall".
Install, update dashboard menu, then go navigate to it in the network-> firewall section

Under IPv4 rules click "add" and paste in the following:
iptables -t mangle -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

add a comment like "fix pppoe maybe" and save the rule.

I know this alone wasn't enough, so I went deeper....

ssh into the clearOS device as root.

run the following commands.

*** backup your config, just in case (yes, I did need it because I ran the command after this with > instead of >> the first time )
# cp /etc/sysconfig/network-scripts/ifcfg-ppp0 ifcfg-ppp0.bkp

*** add the kernel module line to the config
# echo "LINUX_PLUGIN=/usr/lib64/pppd/2.4.5/rp-pppoe.so" >> /etc/sysconfig/network-scripts/ifcfg-ppp0

*** this thing to make it an option?
# echo "plugin rp-pppoe.so" >> /etc/ppp/options

*** reset the connection - replace ppp0 with your ppp interface ID
# ifdown ppp0
# ifup ppp0

after doing all that, speedtest was finally running fast again.

I did also muck about a lot with MTU size on various interfaces but none of that made a difference, so I don't think it's relevant....probably.

Hope that helps the next person to come along.

Thanks for the feedback.

There is only reference to the bug in this thread, but if you look at it, it recommends the following rule is added:

$IPTABLES -t mangle -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Most references put this in the mangle table rather than the filter table (the default if not specified).

Can I also suggest you use the Custom Firewall module to add these rules? They also add a comment to the file.

I had to institute MSS Clamping in order for the websites to show up. So if anyone has the magical combo of ClearOS + CenturyLink + speed and website issues, you may want to try:

edit: /etc/clearos/firewall.d/custom

then add the following line after "if [ "$FW_PROTO" == "ipv4" ]; then true"

$IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

I see there's no response to that previous post from Ryan Anthony, but it deserves one.

I've been tearing my hair out over a PPP via ADSL link which would only run at about 1.5 mbps down and 0.2 mbps up. With a standard cheap modem it was 18 and 1 mbps, about 12 times faster. I tried Ryan's suggestion to disable the Bandwidth & QoS manager, and speeds immediately returned to 18/1. Wheee!

I noted in the documentation that having too small an upload speed configured in the Bandwidth & QoS manager could adversely affect speeds, so I tried it again but configured the speeds as 30000 (30 mbps) down and 2000 up. With Bandwidth QoS manager running and configured with these speeds it ran at the same high speed.

Then I made the mistake of hitting the "Save speed test results" button on the speed test results dialog. This mashed the gains and we were back at 1.5 / 0.2.

Moral of the story - either don't use the Bandwidth & QoS manager, or set the speeds good and high (like maybe double what you expect) and NEVER HIT the "Save speed test results" button after running a speed test.

A bug fix would be nice. Even just removing the button would be an improvement.

Do you have "Bandwidth and QoS Manager" installed/enabled?
If so, consider turning it off.

It will cut your speed tests by approx. half of actual.

HTH

That would be good if you can try the extra MTU setting. The other person I'm helping has just had the MTU set on the PPPoE interface and I'm waiting feedback.

Did you come to any conclusion about ClearOS writing to the ifcfg-ppp0 file? Was it working? If not and it is writing a file with a ~ then probably your changes have no effect.

I'd also bumped into single threaded links on PFSense and possibly FC26. It may be a bit of a red herring as the cpu usage with kernel mode PPPoE seems to be very low, unless you are observing something different. The other system I'm helping with was a Core-i5 and is now a Xeon - way faster than your J1900 but it is still averaging out at a bit over 800Mbps, It may spike higher but does not stay there.

It looks like there are queuing problems with PPPoE with Linux and FreeBSD. I was able to find several references to Intel drivers in FreeBSD and Linux, only being able to receive PPPoE traffic on one driver queue. Apparently this effectively limits PPPoE traffic to one processor. It has been listed as a bug for a couple of years, apparently no one has moved to fix it. Maybe the clear devs could write a patch or push the development community to do so. Here's a couple links on this issue:

https://sourceforge.net/p/e1000/mailman/message/24456397/
https://forum.netgate.com/topic/105662/hardware-for-gigabit-internet/21

I have still not been able to figure out the browsing issue. I did however find one more thing to try, which is to hard code the MTU in the WAN interface settings in addition to the PPPoE file. I am hoping to be able to try it over the next few days.

You can always try a reinstall and start with a minimal one, but I am not sure you'd gain much if you are trying to solve the speed issue. I've seen someone else do that and move it to different hardware (from Core-i5 to Xeon!+ SSD) and it did not help.

If you are trying to solve your connectivity (MTU?), who knows.

I have looked through everything I can find about the web issues and none of the "fixes" have worked. Is it worth trying to re-install clear?

Great work guys, and interesting to see your progress...

One short comment on files ending with "~". This is the common ending made to the backup file created by editors at the start of a file edit. This allows you to recover the original file in case you corrupted it during the edit. (Assuming you didn't do a 'save' within the edit). Editors such as joe, emacs, nano or vi are often configured to do this. I use joe and find this feature very useful and have xxx~ files scattered all over the place. Generally Redhat based apps/scripts ignore these files and they are not a problem Unfortunately the ClearOS apps do not, which is a big nuisance, especially for ifcfg-xxx files as you have found. I come across this all the time as Webconfig has the bad habit of removing lines from ifcfg files where it has no business tampering with them - Webconfig should leave any valid config option within an ifcfg alone - it is too simplistic in its approach. At one time Webconfig failed if you had a comment line with in an ifcfg line (beginning with a '#'). Thankfully this was fixed... Have extra options in ifcfg files so have to live with this annoyance constantly.., and use chattr +i

Bane wrote:

Performance is good with the 1492 MTU, but I still have the website issues. I have tried other MTU settings and nothing is fixing it so far. If I go back to my Century Link router, everything works, so it is definitely a clear OS problem. I have included a screen shot below of the PPPoE settings from the CenturyLink router, that work fine. I have duplicated these settings in clear, but still have the web issue.

Nick Howitt wrote:

Your output suggests to me that the /etc/ppp/options file may not be working, especially if you still have the plugin line in ifcfg-ppp0. I am saying that because I can't see the two switches you added, noccp and nobsdcomp, on your long command line. I had the same thing and without the line in ifcfg-ppp0 and with the plugin line in the options file, my speeds were back to the old, slow speed.

How are you getting on with your mtu? I see you have it at 1492 at the moment.

Performance is good with the 1492 MTU, but I still have the website issues. I have tried other MTU settings and nothing is fixing it so far. If I go back to my Century Link router, everything works, so it is definitely a clear OS problem. I have included a screen shot below of the PPPoE settings from the CenturyLink router, that work fine. I have duplicated these settings in clear, but still have the web issue.

Nick Howitt wrote:

Your output suggests to me that the /etc/ppp/options file may not be working, especially if you still have the plugin line in ifcfg-ppp0. I am saying that because I can't see the two switches you added, noccp and nobsdcomp, on your long command line. I had the same thing and without the line in ifcfg-ppp0 and with the plugin line in the options file, my speeds were back to the old, slow speed.

How are you getting on with your mtu? I see you have it at 1492 at the moment.

Your output suggests to me that the /etc/ppp/options file may not be working, especially if you still have the plugin line in ifcfg-ppp0. I am saying that because I can't see the two switches you added, noccp and nobsdcomp, on your long command line. I had the same thing and without the line in ifcfg-ppp0 and with the plugin line in the options file, my speeds were back to the old, slow speed.

How are you getting on with your mtu? I see you have it at 1492 at the moment.

[root@gateway network-scripts]# ps aux | grep ppp
root 23404 1.3 0.2 454648 18444 ? Ssl 06:03 0:00 /usr/sbin/netifyd -I enp2s0 -E enp1s0 -N ppp0
root 24207 0.0 0.0 9516 1416 ? S 06:03 0:00 /bin/bash /sbin/pppoe-connect /etc/sysconfig/network-scripts/ifcfg-ppp0
root 24241 0.0 0.0 60560 2780 ? Ss 06:03 0:00 /usr/sbin/pppd ipparam ppp0 linkname ppp0 plugin /usr/lib64/pppd/2.4.5/rp-pppoe.so nic-enp1s0 noipdefault noauth default-asyncmap defaultroute hide-password nodetach usepeerdns mtu 1492 mru 1492 noaccomp nodeflate nopcomp novj novjccomp user user@qwest.net lcp-echo-interval 20 lcp-echo-failure 5
root 25570 0.0 0.0 8552 652 ? Ss 06:04 0:00 /usr/sbin/miniupnpd -f /etc/miniupnpd/miniupnpd.conf -i ppp0 -a enp2s0
root 25759 0.0 0.0 112664 972 pts/0 S+ 06:04 0:00 grep --color=auto ppp

Nick Howitt wrote:

Have you by any chance set the immutable bit on the ifcfg-ppp0 file? If so you'll need to unset it with:

chattr -i /etc/sysconfig/network-scripts/ifcfg-ppp0

Remove the ifcfg-ppp0~

I think MTU should be 1492, but try it and see.

I'm trying to help someone elsewhere and changing the options file then restarting the interface did nothing obvious, neither did rebooting. Did you have to restart anything else - but a reboot should have fixed that? Also what do you get from "ps aux | grep ppp"? I am wondering if yours is still using the line from ifcfg-ppp0.

Have you by any chance set the immutable bit on the ifcfg-ppp0 file? If so you'll need to unset it with:

chattr -i /etc/sysconfig/network-scripts/ifcfg-ppp0

Remove the ifcfg-ppp0~

I think MTU should be 1492, but try it and see.

I'm trying to help someone elsewhere and changing the options file then restarting the interface did nothing obvious, neither did rebooting. Did you have to restart anything else - but a reboot should have fixed that? Also what do you get from "ps aux | grep ppp"? I am wondering if yours is still using the line from ifcfg-ppp0.

I haven't had any issues with the /ppp/options file being over written. So far it only seems to be the ifcfg-ppp0. Also, it seems that if the ifcfg-ppp0 file has been locked, something (I am guessing the GUI), creates a a new ifcfg-ppp0~ file.

I believe that if we can get the file overwrite issue corrected and the sites that don't work taken care of, that it will be in a good state, as I can get close to 800mbps with content filtering enabled, which is really the only feature I need beyond firewall, and the standard infrastructure services.

On the MTU, should I be setting it to the full MTU of 1492 in ifcfg-ppp0, or set it to 1464, which is the MTU of 1492 - 28 (header overhead)?

Nick Howitt wrote:

Did you manage to get the /etc/ppp/options file to work?

Did you manage to get the /etc/ppp/options file to work?

I think the MTU should be 1492, but try it. Remember I don't use PPPoE and never have. I've always had cable/ethernet.

If I run "ping 192.168.2.2 -f -l 1472" I get replies, anything higher than 1472 gives me, "packet needs to be fragmented"

If I run ping without the switches for fragementation, I get return time less than 1ms for all packets.

Nick Howitt wrote:

What happens if you do the ping test with clearos.com as your target (it may not help as web traffic could be being redirected)?

So, it appears that using "chattr +i to lock the ifcfg-ppp0 file messes up the GUI. When I use that I get the message "Oooooops: Network Interface is Invalid" when going to the IP settings in the GUI. However if I leave the ifcfg file unlocked (chattr -i), the plugin line gets removed and my speeds get messed up again.

It seems to me that the plugin line needs to be added automatically by clear whenever a PPPoE interface is setup.

Should the MTU be set to 1492 like Centurylink mentioned or should it be set to 1464 (1492 - header overhead)? I am having issues with the same sites I mentioned earlier, again.

Nick Howitt wrote:

Do you still have any gateway anti-virus running? There isn't a disable button, but you can try uninstalling it - it will take out a few other packages (content filter, clamav) but don't worry while testing. Greater upload speeds than download speeds suggest to me more traffic processing on inbound traffic.

I am surprised those noccp and nobsdcomp parameters make much difference as they tell PPPE not to use different forms of compression, but if they do, it is a gain.

Sites failing to load could be an MTU issue. You could perhaps do some MTU testing. There is a classic ping test which you'll need to google for, or just try setting the MTU to something like 1400 or 1350 and use some trial and error.

What happens if you do the ping test with clearos.com as your target (it may not help as web traffic could be being redirected)?

Uninstalling, gateway anti-virus, and all of the IDS/IPS/Attack detector packages didn't make much of a difference. I however, found that uninstalling QoS/Bandwidth manager and Directory server netted me almost 100mb more bandwidth. Bandwidth manager was around 80mbps additional back to my download and Directory server added 10mbps.

Looking at top, it looks to me that the majority of the processes never hit more than core 1 of my 4 core CPU. It looks like it could be a case of more multi threading development work being needed on the processes.

I tested using ping and fragment size of 1464 is where it stops erroring out. So 1464 + 28 for headers equals 1492, which is what Centurylink told me to set it to. I set the MTU for PPPoe to 1464, and that fixed the web sites not working issue, but killed the speed tests. With MTU set to 1464, Download is down to 130mbps and up is at 173.

Nick Howitt wrote:

Do you still have any gateway anti-virus running? There isn't a disable button, but you can try uninstalling it - it will take out a few other packages (content filter, clamav) but don't worry while testing. Greater upload speeds than download speeds suggest to me more traffic processing on inbound traffic.

I am surprised those noccp and nobsdcomp parameters make much difference as they tell PPPE not to use different forms of compression, but if they do, it is a gain.

Sites failing to load could be an MTU issue. You could perhaps do some MTU testing. There is a classic ping test which you'll need to google for, or just try setting the MTU to something like 1400 or 1350 and use some trial and error.

Do you still have any gateway anti-virus running? There isn't a disable button, but you can try uninstalling it - it will take out a few other packages (content filter, clamav) but don't worry while testing. Greater upload speeds than download speeds suggest to me more traffic processing on inbound traffic.

I am surprised those noccp and nobsdcomp parameters make much difference as they tell PPPE not to use different forms of compression, but if they do, it is a gain.

Sites failing to load could be an MTU issue. You could perhaps do some MTU testing. There is a classic ping test which you'll need to google for, or just try setting the MTU to something like 1400 or 1350 and use some trial and error.

Adding noccp and nobsdcomp seems to have increased my bandwidth to 650 down. Upload still hits 940, which is as much as I can expect from upload. I am confused by the difference, especially since I have IDS/IPS, attack detector, proxy, aand content filter turned off.

Also, I am seeing ClearOS fail to give me a result for some websites even though content filtering is off and they work with my CenturyLink router. Interestingly one of the sites is clearos.com, others are missionfed.com and aquasana.com

Nick Howitt wrote:

Comparing a DD-WRT set up which I bumped into to ours, the only real difference is they also set the following parameters:

noccp nobsdcomp nomppe nomppc

Doing a "man pppd", I don't see the nomppc option is valid for us and nomppe is the default.You could try setting the other two values in the /etc/ppp/options file. I don't even know if the DD-WRT setup will handle these speeds, but it could be hardware dependant.

Comparing a DD-WRT set up which I bumped into to ours, the only real difference is they also set the following parameters:

noccp nobsdcomp nomppe nomppc

Doing a "man pppd", I don't see the nomppc option is valid for us and nomppe is the default.You could try setting the other two values in the /etc/ppp/options file. I don't even know if the DD-WRT setup will handle these speeds, but it could be hardware dependant.

Hmm. Reading the man pages enabling the plugin disables the SYNCHRONOUS setting so changing it should have no effect. I don't know what else to suggest.

As you say, the custom firewall rule will make it permanent but use the form "$IPTABLES....." and not "iptables.....".

For the other edit, as mentioned in the bug report, try adding a line to /etc/ppp/options:

plugin rp-pppoe.so

This way the plugin is called from the options file instead. If it does not work, you may need the full path to the plugin, but please report back which works.

There is one further thing to play with and that is the setting SYNCHRONOUS in the ifcfg-pppX file. Try setting it to "yes" and save the file. The interface should restart when you save the file. If it works, to make the change permanent you'll need to set the immutable bit on the file ("chattr +i /etc/sysconfig/network-scripts/ifcfg-ppp0") but then you need to remember you've done it and unset it any time you want a change to the file (for example if you delete the interface through the webconfig to go back to an Ethernet interface)

I did some initial testing, and the performance has increased. The interesting part is that it is now sitting at around 540 down and 900 up. This is with proxy, filtering, and IDS off. So it has improved quite a bit, but not close to my standard century link router which sees 938 down and 900 up.

I don't see a way to make the change permanent. After a reboot, it appears to have been erased out of the ifcfg-ppp0 file. The only thing I see as far as making it permanent is the firewall rule being added via the Web GUI. Is there anyway to add the ifcfg line in the web GUI?

Are there any other tweaks I can make to clear? The CPU doesn't seem to be taxed, and memory is sitting at about 1.6 gb in use of 8gb.

Thanks,

Nick Howitt wrote:

Please see additional comments on Bug 20251. When adding a custom firewall rule, change the "iptables" to "$IPTABLES" and note the alternative way of invoking the plugin which may be better as the webconfig won't overwrite your changes. If you use the alternative way, you may need to use the full path to the plugin.

Please can you post back with your findings?

Please see additional comments on Bug 20251. When adding a custom firewall rule, change the "iptables" to "$IPTABLES" and note the alternative way of invoking the plugin which may be better as the webconfig won't overwrite your changes. If you use the alternative way, you may need to use the full path to the plugin.

Please can you post back with your findings?

From the testing I've been seeing, the latest kernel will probably not help, but I have discovered kernel mode PPPoE. Add the following line to your /etc/sysconfig/network-scripts/ifcfg-ppp0 file:

LINUX_PLUGIN=/usr/lib64/pppd/2.4.5/rp-pppoe.so

Then you can try restarting the PPPoE interface. Check that it has worked by doing "ps aux | grep rp-pppoe". If it finds a looooooong line including a reference to /usr/lib64/pppd/2.4.5/rp-pppoe.so then it is using kernel mode. If it does not find it then either restart networking or reboot. On a Core-i5 machine speeds went up from about 290Mbps to c.790Mbps when testing externally but webconfig consumes reasonable resources when testing using the Webconfig widgit. Better would be to test to a PC behind.

IDS had quite an effect on speeds and note also that the proxy/content filter and Application/Protocol filter can also have an impact. If you have the Application or Protocol filter installed you may need to do a "yum remove netifyd" to disable them completely, including from the firewall.

Hmm, the new updates-testing does not have the required version of linux-firmware so, to install the new kernel:

yum update kernel --enablerepo=clearos-updates-testing,centos-unverified

If it were my machine, I'd probably take a flyer on the new kernel, but that's me. It is also the cheaper and immediate option.

I have seen reports of a StarTech dual USB3 NIC performing at full 1Gb speeds on another distro. Unfortunately in ClearOS it only got up to about 350Mbps.

The D-Link USB 3.0 to Gigabit Ethernet Adapter Model DUB-1312 comes with a tiny CD that has the source for compiling a linux driver compatible with CllearOS 6.x and 7.x. see https://www.dlink.com.au/home-solutions/DUB-1312-usb-3-0-to-gigabit-ethernet-adapter
I have two of these and use them on Mini-ITX Atom boards. The compiled driver is installed at /usr/lib/modules/3.10.0-693.17.1.v7.x86_64/kernel/drivers/net/usb/DUB-13X2.ko
The J1900 would be faster than my Atoms - but would be surprised if you got much over 400 -> 500 Mbit/s - even using a USB3 port. Using iperf with the USB NIC on a USB3 port and connected to a r8168 1 Gbit/s NIC for the results below.

[root@may ~]# iperf -c 192.168.0.16

------------------------------------------------------------

Client connecting to 192.168.0.16, TCP port 5001

TCP window size: 86.2 KByte (default)

------------------------------------------------------------

[  3] local 192.168.0.34 port 35226 connected with 192.168.0.16 port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-10.0 sec   332 MBytes   279 Mbits/sec



[root@alice ~]# iperf -c 192.168.0.16

------------------------------------------------------------

Client connecting to 192.168.0.16, TCP port 5001

TCP window size: 86.2 KByte (default)

------------------------------------------------------------

[  3] local 192.168.0.14 port 49172 connected with 192.168.0.16 port 5001

[ ID] Interval       Transfer     Bandwidth

[  3]  0.0-10.0 sec   294 MBytes   246 Mbits/sec



[root@may ~]# ethtool enp2s0u1 (one of the USB NICs)

Settings for enp2s0u1:

	Supported ports: [ TP MII ]

	Supported link modes:   10baseT/Half 10baseT/Full 

	                        100baseT/Half 100baseT/Full 

	                        1000baseT/Half 1000baseT/Full 

	Supported pause frame use: No

	Supports auto-negotiation: Yes

	Advertised link modes:  10baseT/Half 10baseT/Full 

	                        100baseT/Half 100baseT/Full 

	                        1000baseT/Full 

	Advertised pause frame use: Symmetric

	Advertised auto-negotiation: Yes

	Link partner advertised link modes:  10baseT/Half 10baseT/Full 

	                                     100baseT/Half 100baseT/Full 

	                                     1000baseT/Half 1000baseT/Full 

	Link partner advertised pause frame use: Symmetric Receive-only

	Link partner advertised auto-negotiation: Yes

	Speed: 1000Mb/s

	Duplex: Full

	Port: MII

	PHYAD: 3

	Transceiver: internal

	Auto-negotiation: on

	Supports Wake-on: pg

	Wake-on: g

	Current message level: 0x00000007 (7)

			       drv probe link

	Link detected: yes

Update: ClearOS 7.5 with kernel 3.10.0-862.6.3.v7.x86_64 now supports the D-Link USB 3.0 to Gigabit Ethernet Adapter Model DUB-1312 using the included ax88179_178a driver...

Nick Howitt wrote:
Please can you let me know if this issue is the same as ticket 558584 at Clearcenter?

No it isn't but coincidentally the thread got bumped at about the same time as the ticket after both had been dormant for a while!

It is looking unlikely that the kmod-e1000e driver or even the latest non-kmod one will give you any gain but they are worth trying.

The 7.5 kernel, when it comes out, will come with the same driver as the current kernel, unfortunately. But I believe this kernel comes with other very significant changes which may help if it is not a driver bug but is a kernel bug. I notice the new kernel is available now in the updates-testing repo. I have no idea how safe it is but you can try installing it with a:

yum update kernel --enablerepo=clearos-updates-testing

You will need to reboot for the new kernel to take effect. Note that during boot up it will default to the latest kernel but you get about 5s during the boot to select a different one if necessary. If you try it please report back.

The only other option is to try a USB3 NIC (USB2 has a max speed of 480Mbps). I have absolutely no idea of which USB3 NICs are good in ClearOS.

OK - CPU load and MTU not a problem - sorry, not sure what else to suggest...
Be sure to try the updated driver offered by Nick.

Hmm, so it's a synchronous fibre connection - so even using the modem to do the PPPoE your upload is still way down - 10%, so all is not good even there. Interestingly, the upload is better using the J1900 for PPPoE. Do you happen to know the PCI Express width of the slot the NIC is in - 1x 4x or 8x? My understanding is the Intel 82583V uses the older PCIe v1.0a bus (it was released in 2009 and is a "home" not server product and therefore will not perform the process offloading that the server NICs provide). Just wondering if the bus is a bottleneck. You should be getting close to 1G both ways with a suitable system...

The centurylink supploed C300Z has an MTU of 1492, but setting that on ClearOS made no difference.

Bane wrote:

I thought you were talking about a setting in the PPPoE software on clear. My connection is synchronous, 1gig ( 1 gb up and 1gb down).

Here is a top while running PPPoE and doing a speed test.

op - 14:38:15 up 3:44, 2 users, load average: 0.53, 0.41, 0.24
Tasks: 165 total, 3 running, 162 sleeping, 0 stopped, 0 zombie
%Cpu0 : 15.9 us, 18.5 sy, 0.0 ni, 39.2 id, 0.0 wa, 0.0 hi, 26.4 si, 0.0 st
%Cpu1 : 8.2 us, 7.5 sy, 0.0 ni, 82.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu2 : 11.0 us, 22.7 sy, 0.0 ni, 53.5 id, 0.0 wa, 0.0 hi, 12.7 si, 0.0 st
%Cpu3 : 6.6 us, 16.1 sy, 0.0 ni, 69.4 id, 0.0 wa, 0.0 hi, 7.9 si, 0.0 st
KiB Mem : 8081976 total, 6048784 free, 1159764 used, 873428 buff/cache
KiB Swap: 6254588 total, 6254588 free, 0 used. 6596256 avail Mem

Tony Ellis wrote:

Bane asked "if it is sync or async mode?"

What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?

Tony Ellis wrote:

Bane asked "if it is sync or async mode?"

What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?

I thought you were talking about a setting in the PPPoE software on clear. My connection is synchronous, 1gig ( 1 gb up and 1gb down).

Here is a top while running PPPoE and doing a speed test.

op - 14:38:15 up 3:44, 2 users, load average: 0.53, 0.41, 0.24
Tasks: 165 total, 3 running, 162 sleeping, 0 stopped, 0 zombie
%Cpu0 : 15.9 us, 18.5 sy, 0.0 ni, 39.2 id, 0.0 wa, 0.0 hi, 26.4 si, 0.0 st
%Cpu1 : 8.2 us, 7.5 sy, 0.0 ni, 82.6 id, 0.0 wa, 0.0 hi, 1.7 si, 0.0 st
%Cpu2 : 11.0 us, 22.7 sy, 0.0 ni, 53.5 id, 0.0 wa, 0.0 hi, 12.7 si, 0.0 st
%Cpu3 : 6.6 us, 16.1 sy, 0.0 ni, 69.4 id, 0.0 wa, 0.0 hi, 7.9 si, 0.0 st
KiB Mem : 8081976 total, 6048784 free, 1159764 used, 873428 buff/cache
KiB Swap: 6254588 total, 6254588 free, 0 used. 6596256 avail Mem

Tony Ellis wrote:

Bane asked "if it is sync or async mode?"

What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?

Bane asked "if it is sync or async mode?"

What are the specs for your fibre connection from your ISP - are the upload and download max line rates the same (synchronous), or is the upload a fraction of the download (asynchronous). I suspect from your results the later. When the rates are the same the same bit clock is used for transmission in both directions and hence timing is critical. With asynchronous transmission each direction has its own local independant clock. An example is ADSL where the first letter "A" stands for asynchronous with the upload speed typically 5+% of the download. For instance, my ADSL2+ is 1.14 Mbit/s up and 20.7 Mbit/s down. The synchronous version is SDSL. With cable you will see the term "ATM". Again the first letter is denoting asynchronous.

The J1900 is a slow SoC (System on a Chip). I have a board with the J1800 which is used as a firewall - Multi-Wan with cable and ADSL2+ internet connections. It is quite capable of 1G ethernet as you have found. What I do not know is what additional CPU over head (if any) PPPoE entails. PPPoE can use compression and/or encryption - and if that occurs the slow J1900 may struggle? Run "top" and press the "1" key to see the load on each CPU. Are one or more CPUs running close to 100% when running PPPoE with the modem bridged and running the speed test? How does CPU utilization compare when not bridged?

Did you check the MTU as I described previously - and reduced it to 1492 or a little less if is was set to 1500, to prevent fragmentation?

Below is the ifconfig output. I do not have PPPoE turned on right now. I can send another after I update the drivers and try PPPoE again.

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.234 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::2ba:abff:fe10:2460 prefixlen 64 scopeid 0x20<link>
ether 00:ba:ab:10:24:60 txqueuelen 1000 (Ethernet)
RX packets 1315135 bytes 1620145302 (1.5 GiB)
RX errors 0 dropped 1293 overruns 0 frame 0
TX packets 1220650 bytes 1377451410 (1.2 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xd0900000-d0920000

enp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.3.7 netmask 255.255.255.0 broadcast 192.168.3.255
inet6 fe80::2ba:abff:fe10:2463 prefixlen 64 scopeid 0x20<link>
ether 00:ba:ab:10:24:63 txqueuelen 1000 (Ethernet)
RX packets 1243405 bytes 1382261019 (1.2 GiB)
RX errors 0 dropped 390 overruns 0 frame 0
TX packets 1312026 bytes 1620684828 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19 memory 0xd0600000-d0620000

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 13365 bytes 1472037 (1.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13365 bytes 1472037 (1.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.10.1 netmask 255.255.255.255 destination 10.8.10.2
inet6 fe80::3d6a:b4a:401c:8f5c prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 144 (144.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tun1: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.255 destination 10.8.0.2
inet6 fe80::dbe1:8cd0:266:be2f prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 144 (144.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Nick Howitt wrote:

Can you give me the output of:

ifconfig

Also have you tried the latest kmod-e1000e driver available from here. You will need to reboot afterwards.