slower download speeds from Arch

rv2733 · 2007-07-16 19:10:59

Hello,

I am getting slower download speeds from Arch Linux than from my other distros. I have googled and applied the following "fixes" but they don't improve the download speed.

1. I shut off ipv6:

# /etc/modprobe.conf
alias net-pf-10 off
alias ipv6 off

2. I shut off ipv6 in firefox.

3. Here's my /etc/rc.conf:

DAEMONS=(syslog-ng iptables dhcpcd network netfs portmap ntp crond alsa gpm kdm cpufreq)

lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo eth0)

4. Here's Arch compared with Zenwalk:

Arch vs Zenwalk download and upload speeds by
http://www.speakeasy.net/speedtest/

Arch 17719 kbs down 2049 kbs up

Zenwalk 21537 kbs down 2779 kbs up

5. Ping tests are equal:

Arch: 64 bytes from 64.233.167.99: icmp_seq=1 ttl=242 time=41.2 ms

Zenwalk: 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=34
ttl=242 time=40.5 ms

6. I also tried a different browser, and tried stopping iptables.

Can anyone help?

--
macroron

Lone_Wolf · 2007-07-16 20:10:48

Tests like these can be heavily influenced by the amount of traffic on the internet.

With speedtests on my connection i've gotten differences as big as 20 % between individual tests WITHOUT CHANGING ANYTHING.

Did you run multiple tests and averaged the results ?
Where the tests with arch / Zenwalk done close in time ?

rv2733 · 2007-07-16 21:58:54

Lone_Wolf wrote:

Tests like these can be heavily influenced by the amount of traffic on the internet.
With speedtests on my connection i've gotten differences as big as 20 % between individual tests WITHOUT CHANGING ANYTHING.
Did you run multiple tests and averaged the results ?
Where the tests with arch / Zenwalk done close in time ?

Yes, I have run multiple tests and tested both very close in time. I also tested fedora 7 and slackware. Arch is the only one that tested lower.

--
macroron

rv2733 · 2007-07-16 23:08:01

rv2733 wrote:

Hello,
I am getting slower download speeds from Arch Linux than from my other distros. I have googled and applied the following "fixes" but they don't improve the download speed.
1. I shut off ipv6:
# /etc/modprobe.conf
alias net-pf-10 off
alias ipv6 off
2. I shut off ipv6 in firefox.
3. Here's my /etc/rc.conf:
DAEMONS=(syslog-ng iptables dhcpcd network netfs portmap ntp crond alsa gpm kdm cpufreq)
lo="lo 127.0.0.1"
eth0="dhcp"
INTERFACES=(lo eth0)
4. Here's Arch compared with Zenwalk:
Arch vs Zenwalk download and upload speeds by
http://www.speakeasy.net/speedtest/
Arch 17719 kbs down 2049 kbs up
Zenwalk 21537 kbs down 2779 kbs up
5. Ping tests are equal:
Arch: 64 bytes from 64.233.167.99: icmp_seq=1 ttl=242 time=41.2 ms
Zenwalk: 64 bytes from py-in-f99.google.com (64.233.167.99): icmp_seq=34
ttl=242 time=40.5 ms
6. I also tried a different browser, and tried stopping iptables.
Can anyone help?
--
macroron

7. I also tied changing '/etc/rc.conf' :

DAEMONS=(syslog-ng iptables dhcpcd network netfs portmap ntpd crond alsa gpm kdm cpufreq)

To this:

DAEMONS=(syslog-ng !iptables !dhcpcd network !netfs !portmap !ntpd crond alsa gpm kdm cpufreq)

--
macroron

judfilm · 2007-07-17 01:41:51

Just some basic questions first:
same Kernel version? ie 2.6.21.6
same Scheduler? ie CFQ
any additions to /etc/sysctl.conf?

To everyone: Please add any other ideas to narrow this down, every little bit helps make Arch even better.

rv2733 · 2007-07-17 03:19:48

judfilm wrote:

Just some basic questions first:
same Kernel version? ie 2.6.21.6
same Scheduler? ie CFQ
any additions to /etc/sysctl.conf?
To everyone: Please add any other ideas to narrow this down, every little bit helps make Arch even better.

Hello,

This is a new Arch Base install. ArchLinux-i686-2007.05-Duke.base.

Here is some info:

# uname -a

Linux arch 2.6.21-ARCH #1 SMP PREEMPT Sat Jul 7 09:57:11 UTC 2007 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

---

# cat messages.log | grep 'io scheduler'

Jul 16 14:36:53 arch io scheduler noop registered
Jul 16 14:36:53 arch io scheduler anticipatory registered
Jul 16 14:36:53 arch io scheduler deadline registered
Jul 16 14:36:53 arch io scheduler cfq registered (default)

---

#
# Kernel sysctl configuration
#

# Disable packet forwarding
net.ipv4.ip_forward=0

# Disable the magic-sysrq key
kernel.sysrq = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

---

# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:11:D8:CF:C4:8C
inet addr:67.191.85.73 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:576 Metric:1
RX packets:52937 errors:0 dropped:0 overruns:0 frame:0
TX packets:11701 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:12267165 (11.6 Mb) TX bytes:2727043 (2.6 Mb)
Interrupt:17 Base address:0x4000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:116 errors:0 dropped:0 overruns:0 frame:0
TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:7016 (6.8 Kb) TX bytes:7016 (6.8 Kb)

---

# Generated by iptables-save v1.3.8 on Sat Jul 14 22:52:00 2007
*nat
:PREROUTING ACCEPT [521:189500]
:POSTROUTING ACCEPT [142:7606]
:OUTPUT ACCEPT [142:7606]
COMMIT
# Completed on Sat Jul 14 22:52:00 2007
# Generated by iptables-save v1.3.8 on Sat Jul 14 22:52:00 2007
*mangle
:PREROUTING ACCEPT [2705:1004924]
:INPUT ACCEPT [2705:1004924]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1991:234774]
:POSTROUTING ACCEPT [1991:234774]
COMMIT
# Completed on Sat Jul 14 22:52:00 2007
# Generated by iptables-save v1.3.8 on Sat Jul 14 22:52:00 2007
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [173:14461]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 127.0.0.0/255.0.0.0 -d 127.0.0.0/255.0.0.0 -i lo -j ACCEPT
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -j LOG
-A INPUT -j DROP
COMMIT
# Completed on Sat Jul 14 22:52:00 2007

--
macroron

judfilm · 2007-07-17 06:43:11

How do the Arch Settings compare to the other Distro's you have tried?

rv2733 · 2007-07-17 09:17:35

judfilm wrote:

How do the Arch Settings compare to the other Distro's you have tried?

As part of my evaluation of any distro I have been using Speak Easy Nets' Speed Test <http://www.speakeasy.net/speedtest/>. I take weekly tests of each distro and record them. Averaging them out gives me a good comparison number. Out of the four distros I have installed Arch is the only one that shows a lower download speed. I would like to know why?

Here is comparison info for Zenwalk Linux:

# uname -a

Linux zenwalk 2.6.21.3 #1 SMP PREEMPT Mon May 28 20:42:52 CEST 2007 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

---

# cat /var/log/messages | grep 'io scheduler'

Jul 17 08:40:13 (none) kernel: io scheduler noop registered
Jul 17 08:40:13 (none) kernel: io scheduler cfq registered (default)

---

# cat /etc/sysctl.conf

EMPTY

---

# ifconfig

eth0 Link encap:Ethernet HWaddr 00:11:D8:CF:C4:8C
inet addr:67.191.85.73 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:19365 errors:0 dropped:0 overruns:0 frame:0
TX packets:1104 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1820703 (1.7 MiB) TX bytes:317521 (310.0 KiB)
Interrupt:19 Base address:0xc000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

---

# Generated by iptables-save v1.3.7 on Sun Jul 8 22:53:32 2007
*mangle
:PREROUTING ACCEPT [167:14670]
:INPUT ACCEPT [164:13896]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [164:13896]
:POSTROUTING ACCEPT [164:13896]
COMMIT
# Completed on Sun Jul 8 22:53:32 2007
# Generated by iptables-save v1.3.7 on Sun Jul 8 22:53:32 2007
*nat
:PREROUTING ACCEPT [3:774]
:POSTROUTING ACCEPT [2:128]
:OUTPUT ACCEPT [2:128]
COMMIT
# Completed on Sun Jul 8 22:53:32 2007
# Generated by iptables-save v1.3.7 on Sun Jul 8 22:53:32 2007
*filter
:INPUT ACCEPT [164:13896]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [164:13896]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j DROP
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT
# Completed on Sun Jul 8 22:53:32 2007

---

PING google.com (64.233.187.99) 56(84) bytes of data.
64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=243 time=24.2 ms

---

Screenshot: Arch.png http://myaccount.dropsend.com/pickup/1c33132a13900fa1

Arch Download: 17544 kbps Upload: 1995 kbps

Zenwalk Download: 21741 kbps Upload: 2779 kbps

---
macroron

Last edited by rv2733 (2007-07-17 09:37:31)

timtux · 2007-07-17 17:05:15

It's a flash based test thats is far from accurate.

However, that test gives me this results:
11768kb/s 8126kb/s

You should try out tptest instead ( http://tptest.sf.net )

TPTEST was originally developed by the Swedish ICT-commission (Government stuff), then later by the Foundation for Internet Infrastructure (iis.se), the Swedish Consumer Agency (konsumentverket.se), and the Swedish National Post- and Telecom Agency (pts.se). The latest development has been to separate the platform-independent test method software (the test engine) from the platform-dependent user interface software in order to make it easier for anyone to write a test client or server that uses the TPTEST testing method. The test engine code is to be regarded as a library module and is released under the LGPL license while the reference client/server applications is released under the GPL license.

Wich gives me more accurate numbers:

[tim@timtux client]$ ./tptestclient -v 2 -m ta referens.sth.ip-performance.se 1641 |grep TCP
TCP Send: 11596035 bps (11.60 Mbit/s)
TCP Recv: 14533810 bps (14.53 Mbit/s)

Yay, the government develops good open source software for my tax money.

Last edited by timtux (2007-07-17 17:48:15)

rv2733 · 2007-07-17 19:05:53

timtux wrote:

It's a flash based test thats is far from accurate.
However, that test gives me this results:
11768kb/s 8126kb/s
You should try out tptest instead ( http://tptest.sf.net )
Wich gives me more accurate numbers:
[tim@timtux client]$ ./tptestclient -v 2 -m ta referens.sth.ip-performance.se 1641 |grep TCP
TCP Send: 11596035 bps (11.60 Mbit/s)
TCP Recv: 14533810 bps (14.53 Mbit/s)
Yay, the government develops good open source software for my tax money.

Hello,

By using the same test and periodically recording the speed over the last year, I have an averaged set of numbers to compare the speed of distros. The Speak Easy speed test has been the most consistent test I have found. I wasn't looking for accuracy. With these numbers I can tell when there is any fluctuation from the norm. All the other distros averaged numbers are close to one another except Arch and the following tests seem to agree with my findings.

Anyway TPTEST looks like what I need. Thank You. I'll let you know my results after I study this some more.

----

Arch compared to Fedora 7:

1. Large file download (284M):

Arch: 727.72 KB/s real 6m39.515s

Fedora: 792.15 KB/s real 6m6.913s

Speed Test:

Arch: 17478 kbps 1974 kbps

Fedora: 21658 kbps 2767 kbps

-----

Arch:

# time wget http://videos.revision3.com/diggnation/ … e.xvid.avi

--14:07:33-- http://videos.revision3.com/diggnation/ … e.xvid.avi
=> `diggnation--0106--2007-07-12hippie--large.xvid.avi'
Resolving videos.revision3.com... 205.234.175.175
Connecting to videos.revision3.com|205.234.175.175|:80.. . connected.
HTTP request sent, awaiting response... 200 OK
Length: 297,442,510 (284M) [video/x-msvideo]

100%[====================================>] 297,442,510 708.22K/s ETA 00:00

14:14:12 (727.72 KB/s) - `diggnation--0106--2007-07-12hippie--large.xvid.avi' saved [297442510/297442510]

real 6m39.515s
user 0m1.020s
sys 0m9.953s

----

Speed Test:

Download Speed: 17478 kbps ( 2184.8 KB/sec transfer rate)
Upload Speed: 1974 kbps (246.8 KB/sec transfer rate)

----

fedora 7:

$ time wget http://videos.revision3.com/diggnation/ … e.xvid.avi

--13:40:30-- http://videos.revision3.com/diggnation/ … e.xvid.avi
=> `diggnation--0106--2007-07-12hippie--large.xvid.avi'
Resolving videos.revision3.com... 205.234.175.175
Connecting to videos.revision3.com|205.234.175.175|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 297,442,510 (284M) [video/x-msvideo]

100%[==========================>] 297,442,510 768.89K/s ETA 00:00z

13:46:37 (792.15 KB/s) - `diggnation--0106--2007-07-12hippie--large.xvid.avi' saved [297442510/297442510]

real 6m6.913s
user 0m0.836s
sys 0m6.902s

----

Speed Test:

Download Speed: 21658 kbps (2707.3 KB/sec transfer rate)

Upload Speed: 2767 kbps (345.9 KB/sec transfer rate)

----
macroron

Last edited by rv2733 (2007-07-17 19:12:37)

timtux · 2007-07-17 19:27:09

Then i would encourage you to try a different NIC. It's probelity
some driver issue as no one else has noticed this problem.

rv2733 · 2007-07-17 19:48:30

timtux wrote:

Then i would encourage you to try a different NIC. It's probelity
some driver issue as no one else has noticed this problem.

Thank You,

I was just about to ask about kernel modules/drivers. forcedeth is the nic driver, I think. But i have no idea how to correct something that's compiled in. I will stay with what I have for now. until I learn somemore. I like Arch Linux and plan to stay with it.

--
macroron

MODULES=(powernow-k8 forcedeth slhc ac97_bus snd-mixer-oss snd-pcm-oss snd-seq-oss snd-seq-device snd-seq-midi-event snd-seq snd-page-alloc snd-pcm snd-rawmidi snd-timer snd snd-mpu401-uart snd-mpu401 snd-ac97-codec snd-intel8x0 soundcore)

# lsmod

Module Size Used by
nvidia 7239028 24
agpgart 27352 1 nvidia
cpufreq_ondemand 6796 1
ipt_LOG 6272 1
xt_tcpudp 3328 1
xt_state 2432 1
iptable_filter 2688 1
iptable_mangle 2560 0
iptable_nat 6404 0
nf_nat 15532 1 iptable_nat
nf_conntrack_ipv4 14092 3 iptable_nat
nf_conntrack 51720 4 xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4
nfnetlink 5272 3 nf_nat,nf_conntrack_ipv4,nf_conntrack
ip_tables 10452 3 iptable_filter,iptable_mangle,iptable_nat
x_tables 12036 5 ipt_LOG,xt_tcpudp,xt_state,iptable_nat,ip_tables
analog 10272 0
ppdev 7556 0
lp 9220 0
ns558 4224 0
gameport 11784 3 analog,ns558
ppp_generic 23572 0
psmouse 34952 0
serio_raw 5636 0
parport_pc 35172 1
parport 31176 3 ppdev,lp,parport_pc
rtc_sysfs 3840 0
rtc_proc 3844 0
rtc_dev 6664 0
rtc_cmos 7188 0
rtc_core 7684 4 rtc_sysfs,rtc_proc,rtc_dev,rtc_cmos
rtc_lib 3456 2 rtc_sysfs,rtc_core
k8temp 4736 0
pcspkr 2944 0
usbhid 36128 0
hid 24448 1 usbhid
ff_memless 5256 1 usbhid
sg 26524 0
i2c_nforce2 5120 0
i2c_core 17536 2 nvidia,i2c_nforce2
tsdev 6464 0
evdev 8192 0
thermal 11528 0
fan 3972 0
button 6288 0
battery 8452 0
ac 4100 0
snd_intel8x0 28700 2
snd_ac97_codec 95780 1 snd_intel8x0
snd_mpu401 6760 0
snd_mpu401_uart 7040 1 snd_mpu401
snd_rawmidi 19104 1 snd_mpu401_uart
snd_seq_oss 29056 0
snd_seq_midi_event 6528 1 snd_seq_oss
snd_seq 46544 4 snd_seq_oss,snd_seq_midi_event
snd_seq_device 6796 3 snd_rawmidi,snd_seq_oss,snd_seq
snd_pcm_oss 38688 0
snd_pcm 69124 4 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 19076 3 snd_seq,snd_pcm
snd_page_alloc 7816 2 snd_intel8x0,snd_pcm
snd_mixer_oss 14592 1 snd_pcm_oss
snd 44516 14 snd_intel8x0,snd_ac97_codec,snd_mpu401,snd_mpu401_uart,snd_rawmidi,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
soundcore 6368 1 snd
ac97_bus 2432 1 snd_ac97_codec
slhc 5760 1 ppp_generic
forcedeth 42888 0
powernow_k8 12948 0
freq_table 3984 2 cpufreq_ondemand,powernow_k8
processor 24532 2 thermal,powernow_k8
ext3 119176 1
jbd 54312 1 ext3
mbcache 6916 1 ext3
sd_mod 17796 3
sr_mod 14372 0
cdrom 34464 1 sr_mod
ehci_hcd 30732 0
ohci_hcd 19588 0
usbcore 111240 4 usbhid,ehci_hcd,ohci_hcd
sata_nv 15748 2
ata_generic 5636 0
pata_amd 10380 0
libata 103060 3 sata_nv,ata_generic,

--

timtux · 2007-07-17 22:54:36

Hum, i'm using the same module. Can you please do a lspci|grep Ethernet and paste the output?

Last edited by timtux (2007-07-17 22:54:51)

rv2733 · 2007-07-17 23:15:51

timtux wrote:

Hum, i'm using the same module. Can you please do a lspci|grep Ethernet and paste the output?

Here it is:

# /sbin/lspci |grep Ethernet

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

Mother Board: Asus A8n-e

--

timtux · 2007-07-17 23:22:27

Strange, i got the exact same NIC and driver. However, i dont have any slowdowns. Using the 2.6.22.

rv2733 · 2007-07-17 23:46:55

timtux wrote:

Strange, i got the exact same NIC and driver. However, i dont have any slowdowns. Using the 2.6.22.

If it doesn't occur with the other three distros I have installed, using the same hardware, then it has to be My Arch configuration. No? Remember, this is a new install, and I'm using the default kernel26.img.

lucke · 2007-07-17 23:58:24

Perhaps it's some 2.6.21/22 regression? What kernel are you using in Arch and other distros?

cactus · 2007-07-18 00:05:03

testing troughput over the internet is a HORRIBLE way to compare any distribution. There are so many factors...so many...that could be coming into play.

checksum offloading, tcp window scale problems with upstream routers, network congestion, packet loss, latency, tcp backoff algorithm choice, popularity of the site you are going to, time of day for overall network traffic, what color your pants are...

The best way to test throughput is probably going to be the use of iperf over a local lan connection to a machine that does not change across tests.

However, if you do some traffic analysis, you *might* find some sort of anomaly....
Fire up wireshark and take some captures. See if anything looks exceedingly funky.

rv2733 · 2007-07-18 00:18:19

lucke wrote:

Perhaps it's some 2.6.21/22 regression? What kernel are you using in Arch and other distros?

Arch: vmlinuz26 linux-2.6.21-ARCH
Fedora 7: vmlinuz-2.6.21-1.3228.fc7
Slackware: vmlinuz-huge-smp-2.6.21.5-smp
Zenwalk: vmlinuz-2.6.21.3

--

rv2733 · 2007-07-18 00:28:13

cactus wrote:

testing troughput over the internet is a HORRIBLE way to compare any distribution. There are so many factors...so many...that could be coming into play.
checksum offloading, tcp window scale problems with upstream routers, network congestion, packet loss, latency, tcp backoff algorithm choice, popularity of the site you are going to, time of day for overall network traffic, what color your pants are...
The best way to test throughput is probably going to be the use of iperf over a local lan connection to a machine that does not change across tests.
However, if you do some traffic analysis, you *might* find some sort of anomaly....
Fire up wireshark and take some captures. See if anything looks exceedingly funky.

Hello,

Points taken. But if one out of four distros takes a significantly longer time to download the same large file, from the same address, using the same hardware, at about the same time, then what. I am curious. This is how I learn.

--
macroron

lucke · 2007-07-18 00:42:46

If you're stuck on it, you could build Arch kernel package with a kernel config from any of those "faster" distros and see whether there's any improvement.

msoltyspl · 2007-07-18 11:22:32

rv2733 wrote:

Points taken. But if one out of four distros takes a significantly longer time to download the same large file, from the same address, using the same hardware, at about the same time, then what. I am curious. This is how I learn.
--
macroron

What about your tcp window settings, compared to other distros (wmem_max, rmem_max, tcp_wmem, tcp_rmem, etc.) ? They might play important role, depending on your bandwidth and latency to test server.

rv2733 · 2007-07-18 12:04:37

msoltyspl wrote:

[What about your tcp window settings, compared to other distros (wmem_max, rmem_max, tcp_wmem, tcp_rmem, etc.) ? They might play important role, depending on your bandwidth and latency to test server.

Hello,

"Googling" for solutions, I see many suggestions to "improve" performance. Most over my head. I'm trying to isolate the obvious first. I was hoping someone here could compare a simple timed download of a large file using another distro with Arch using the same file and hardware. This would isolate the problem to my configuration. Here are the /etc/sysctl.conf files:

1. Fedora 7:

# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 1

2. Arch:

#
# Kernel sysctl configuration
#

# Disable packet forwarding
net.ipv4.ip_forward=0

# Disable the magic-sysrq key
kernel.sysrq = 0

# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1

3. Slackware:

EMPTY

USES BIG KERNEL WITH DRIVER MODULES COMPILED IN

4. Zenwalk

EMPTY

--
macroron

Last edited by rv2733 (2007-07-18 12:06:03)

timtux · 2007-07-18 14:30:19

http://wwwx.cs.unc.edu/~sparkst/howto/n … tuning.php

Try this?

rv2733 · 2007-07-18 15:44:42

timtux wrote:

http://wwwx.cs.unc.edu/~sparkst/howto/n … tuning.php
Try this?

Thank You,

I will give the tcp window settings "howto" a try. Am I right in assuming that all kernels are compiled with different configuration settings and patches?

--
macroron

Arch Linux

#1 2007-07-16 19:10:59

slower download speeds from Arch

#2 2007-07-16 20:10:48

Re: slower download speeds from Arch

#3 2007-07-16 21:58:54

Re: slower download speeds from Arch

#4 2007-07-16 23:08:01

Re: slower download speeds from Arch

#5 2007-07-17 01:41:51

Re: slower download speeds from Arch

#6 2007-07-17 03:19:48

Re: slower download speeds from Arch

#7 2007-07-17 06:43:11

Re: slower download speeds from Arch

#8 2007-07-17 09:17:35

Re: slower download speeds from Arch

#9 2007-07-17 17:05:15

Re: slower download speeds from Arch

#10 2007-07-17 19:05:53

Re: slower download speeds from Arch

#11 2007-07-17 19:27:09

Re: slower download speeds from Arch

#12 2007-07-17 19:48:30

Re: slower download speeds from Arch

#13 2007-07-17 22:54:36

Re: slower download speeds from Arch

#14 2007-07-17 23:15:51

Re: slower download speeds from Arch

#15 2007-07-17 23:22:27

Re: slower download speeds from Arch

#16 2007-07-17 23:46:55

Re: slower download speeds from Arch

#17 2007-07-17 23:58:24

Re: slower download speeds from Arch

#18 2007-07-18 00:05:03

Re: slower download speeds from Arch

#19 2007-07-18 00:18:19

Re: slower download speeds from Arch

#20 2007-07-18 00:28:13

Re: slower download speeds from Arch

#21 2007-07-18 00:42:46

Re: slower download speeds from Arch

#22 2007-07-18 11:22:32

Re: slower download speeds from Arch

#23 2007-07-18 12:04:37

Re: slower download speeds from Arch

#24 2007-07-18 14:30:19

Re: slower download speeds from Arch

#25 2007-07-18 15:44:42

Re: slower download speeds from Arch

Board footer