Re: unfair scheduling with tbb application observed, could it be a kernel issue?
I didn't enable cgroups explicitly, and don't have userspace tools for that installed. Thanks. Pedro. On Mon, Aug 6, 2012 at 4:25 PM, Mike Galbraith wrote: > On Mon, 2012-08-06 at 16:04 +0200, Pedro Larroy wrote: >> Hi >> >> I think we are observing unfair scheduling of processes that use intel >> TBB thread scheduler, as we have several processes with nice of 19 and >> ioniced idle, and somehow the process with nice 0 should be getting >> more than 1000% cpu > .. >> Tasks: 559 total, 37 running, 522 sleeping, 0 stopped, 0 zombie >> Cpu(s): 67.8%us, 16.0%sy, 13.0%ni, 1.7%id, 0.6%wa, 0.0%hi, 1.0%si, >> 0.0%st >> Mem: 98998032k total, 97444688k used, 1553344k free,53772k buffers >> Swap: 4198316k total, 704860k used, 3493456k free, 73270776k cached >> >> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND >> 14373 disco 39 19 8734m 6.9g 12m R 107 7.3 36:09.72 mmcc >> 15293 disco 39 19 3174m 1.4g 12m R 101 1.5 19:33.79 mmcc >> 20341 disco 39 19 2735m 1.1g 12m R 101 1.1 8:40.38 mmcc >> 18241 disco 39 19 3040m 1.3g 11m R 100 1.4 14:27.91 mmcc >> 15204 disco 39 19 5418m 3.7g 12m R 99 3.9 20:53.89 mmcc >> 24901 larroy20 0 327m 296m 4276 R 88 0.3 0:04.14 cc1plus >> 24942 larroy20 0 193m 159m 4008 R 87 0.2 0:01.47 cc1plus >> 24862 larroy20 0 417m 388m 7992 R 84 0.4 0:07.02 cc1plus >> 24959 larroy20 0 184m 153m 4008 R 80 0.2 0:01.32 cc1plus >> 24935 larroy20 0 254m 222m 4024 R 77 0.2 0:02.44 cc1plus >> 24919 larroy20 0 336m 301m 4036 R 76 0.3 0:03.61 cc1plus >> 24972 larroy20 0 43160 15m 2332 R 76 0.0 0:00.95 cc1plus >> 24918 larroy20 0 287m 255m 4024 R 70 0.3 0:02.99 cc1plus >> 24962 larroy20 0 44872 17m 2332 R 69 0.0 0:01.23 cc1plus >> 24976 larroy20 0 41212 14m 2332 R 66 0.0 0:00.67 cc1plus >> 24501 larroy20 0 687m 657m 8044 R 64 0.7 0:22.97 cc1plus >> 24933 larroy20 0 211m 177m 4008 R 62 0.2 0:01.79 cc1plus >> 24899 larroy20 0 327m 296m 4276 R 57 0.3 0:04.25 cc1plus > > Are tasks running in per user cgroups or such? If so, you'd need to > adjust group shares. > > -Mike > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unfair scheduling with tbb application observed, could it be a kernel issue?
Hi I think we are observing unfair scheduling of processes that use intel TBB thread scheduler, as we have several processes with nice of 19 and ioniced idle, and somehow the process with nice 0 should be getting more than 1000% cpu Any ideas? Kernel is 3.0.0.-17-generic on unbutu 11.10. Avg[99.6%] Tasks: 331; 81 running Mem[36386/96868MB] Load average: 76.99 46.08 34.32 Swp[| 534/4099MB] Time: 15:51:51 PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 10597 disco 39 19 6772M 6366M 14384 R 636. 6.6 37:56.63 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 178 -c /map_store/de 11629 visciano 20 0 6106M 5504M 18668 R 585. 5.7 39:02.15 build/release/mmcc -D --compact -f 8 -h bfmapcomp03.europe.nokia.com -d 1521 -s LDMTEST - 10235 disco 39 19 4566M 4190M 12512 R 197. 4.3 25:13.58 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 183 -c /map_store/de 11599 disco 39 19 4935M 4644M 12572 R 188. 4.8 15:44.48 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 176 -c /map_store/de 11996 disco 39 19 4407M 4164M 12580 R 103. 4.3 12:08.25 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 174 -c /map_store/de 12630 disco 39 19 1804M 1589M 12248 R 101. 1.6 4:31.51 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 172 -c /map_store/de Another example, the processes at 100% not being throttled at all when having more processes waiting with higher priority: Tasks: 559 total, 37 running, 522 sleeping, 0 stopped, 0 zombie Cpu(s): 67.8%us, 16.0%sy, 13.0%ni, 1.7%id, 0.6%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 98998032k total, 97444688k used, 1553344k free,53772k buffers Swap: 4198316k total, 704860k used, 3493456k free, 73270776k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14373 disco 39 19 8734m 6.9g 12m R 107 7.3 36:09.72 mmcc 15293 disco 39 19 3174m 1.4g 12m R 101 1.5 19:33.79 mmcc 20341 disco 39 19 2735m 1.1g 12m R 101 1.1 8:40.38 mmcc 18241 disco 39 19 3040m 1.3g 11m R 100 1.4 14:27.91 mmcc 15204 disco 39 19 5418m 3.7g 12m R 99 3.9 20:53.89 mmcc 24901 larroy20 0 327m 296m 4276 R 88 0.3 0:04.14 cc1plus 24942 larroy20 0 193m 159m 4008 R 87 0.2 0:01.47 cc1plus 24862 larroy20 0 417m 388m 7992 R 84 0.4 0:07.02 cc1plus 24959 larroy20 0 184m 153m 4008 R 80 0.2 0:01.32 cc1plus 24935 larroy20 0 254m 222m 4024 R 77 0.2 0:02.44 cc1plus 24919 larroy20 0 336m 301m 4036 R 76 0.3 0:03.61 cc1plus 24972 larroy20 0 43160 15m 2332 R 76 0.0 0:00.95 cc1plus 24918 larroy20 0 287m 255m 4024 R 70 0.3 0:02.99 cc1plus 24962 larroy20 0 44872 17m 2332 R 69 0.0 0:01.23 cc1plus 24976 larroy20 0 41212 14m 2332 R 66 0.0 0:00.67 cc1plus 24501 larroy20 0 687m 657m 8044 R 64 0.7 0:22.97 cc1plus 24933 larroy20 0 211m 177m 4008 R 62 0.2 0:01.79 cc1plus 24899 larroy20 0 327m 296m 4276 R 57 0.3 0:04.25 cc1plus This is 3.2.0-26-generic on ubuntu 12.04 Regards. Pedro. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unfair scheduling with tbb application observed, could it be a kernel issue?
Hi I think we are observing unfair scheduling of processes that use intel TBB thread scheduler, as we have several processes with nice of 19 and ioniced idle, and somehow the process with nice 0 should be getting more than 1000% cpu Any ideas? Kernel is 3.0.0.-17-generic on unbutu 11.10. Avg[99.6%] Tasks: 331; 81 running Mem[36386/96868MB] Load average: 76.99 46.08 34.32 Swp[| 534/4099MB] Time: 15:51:51 PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 10597 disco 39 19 6772M 6366M 14384 R 636. 6.6 37:56.63 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 178 -c /map_store/de 11629 visciano 20 0 6106M 5504M 18668 R 585. 5.7 39:02.15 build/release/mmcc -D --compact -f 8 -h bfmapcomp03.europe.nokia.com -d 1521 -s LDMTEST - 10235 disco 39 19 4566M 4190M 12512 R 197. 4.3 25:13.58 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 183 -c /map_store/de 11599 disco 39 19 4935M 4644M 12572 R 188. 4.8 15:44.48 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 176 -c /map_store/de 11996 disco 39 19 4407M 4164M 12580 R 103. 4.3 12:08.25 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 174 -c /map_store/de 12630 disco 39 19 1804M 1589M 12248 R 101. 1.6 4:31.51 /map_store/developers/disco/12_08_06-13_53_1344254009-j3UGmL/mmcc -X 172 -c /map_store/de Another example, the processes at 100% not being throttled at all when having more processes waiting with higher priority: Tasks: 559 total, 37 running, 522 sleeping, 0 stopped, 0 zombie Cpu(s): 67.8%us, 16.0%sy, 13.0%ni, 1.7%id, 0.6%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 98998032k total, 97444688k used, 1553344k free,53772k buffers Swap: 4198316k total, 704860k used, 3493456k free, 73270776k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14373 disco 39 19 8734m 6.9g 12m R 107 7.3 36:09.72 mmcc 15293 disco 39 19 3174m 1.4g 12m R 101 1.5 19:33.79 mmcc 20341 disco 39 19 2735m 1.1g 12m R 101 1.1 8:40.38 mmcc 18241 disco 39 19 3040m 1.3g 11m R 100 1.4 14:27.91 mmcc 15204 disco 39 19 5418m 3.7g 12m R 99 3.9 20:53.89 mmcc 24901 larroy20 0 327m 296m 4276 R 88 0.3 0:04.14 cc1plus 24942 larroy20 0 193m 159m 4008 R 87 0.2 0:01.47 cc1plus 24862 larroy20 0 417m 388m 7992 R 84 0.4 0:07.02 cc1plus 24959 larroy20 0 184m 153m 4008 R 80 0.2 0:01.32 cc1plus 24935 larroy20 0 254m 222m 4024 R 77 0.2 0:02.44 cc1plus 24919 larroy20 0 336m 301m 4036 R 76 0.3 0:03.61 cc1plus 24972 larroy20 0 43160 15m 2332 R 76 0.0 0:00.95 cc1plus 24918 larroy20 0 287m 255m 4024 R 70 0.3 0:02.99 cc1plus 24962 larroy20 0 44872 17m 2332 R 69 0.0 0:01.23 cc1plus 24976 larroy20 0 41212 14m 2332 R 66 0.0 0:00.67 cc1plus 24501 larroy20 0 687m 657m 8044 R 64 0.7 0:22.97 cc1plus 24933 larroy20 0 211m 177m 4008 R 62 0.2 0:01.79 cc1plus 24899 larroy20 0 327m 296m 4276 R 57 0.3 0:04.25 cc1plus This is 3.2.0-26-generic on ubuntu 12.04 Regards. Pedro. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: unfair scheduling with tbb application observed, could it be a kernel issue?
I didn't enable cgroups explicitly, and don't have userspace tools for that installed. Thanks. Pedro. On Mon, Aug 6, 2012 at 4:25 PM, Mike Galbraith efa...@gmx.de wrote: On Mon, 2012-08-06 at 16:04 +0200, Pedro Larroy wrote: Hi I think we are observing unfair scheduling of processes that use intel TBB thread scheduler, as we have several processes with nice of 19 and ioniced idle, and somehow the process with nice 0 should be getting more than 1000% cpu .. Tasks: 559 total, 37 running, 522 sleeping, 0 stopped, 0 zombie Cpu(s): 67.8%us, 16.0%sy, 13.0%ni, 1.7%id, 0.6%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 98998032k total, 97444688k used, 1553344k free,53772k buffers Swap: 4198316k total, 704860k used, 3493456k free, 73270776k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14373 disco 39 19 8734m 6.9g 12m R 107 7.3 36:09.72 mmcc 15293 disco 39 19 3174m 1.4g 12m R 101 1.5 19:33.79 mmcc 20341 disco 39 19 2735m 1.1g 12m R 101 1.1 8:40.38 mmcc 18241 disco 39 19 3040m 1.3g 11m R 100 1.4 14:27.91 mmcc 15204 disco 39 19 5418m 3.7g 12m R 99 3.9 20:53.89 mmcc 24901 larroy20 0 327m 296m 4276 R 88 0.3 0:04.14 cc1plus 24942 larroy20 0 193m 159m 4008 R 87 0.2 0:01.47 cc1plus 24862 larroy20 0 417m 388m 7992 R 84 0.4 0:07.02 cc1plus 24959 larroy20 0 184m 153m 4008 R 80 0.2 0:01.32 cc1plus 24935 larroy20 0 254m 222m 4024 R 77 0.2 0:02.44 cc1plus 24919 larroy20 0 336m 301m 4036 R 76 0.3 0:03.61 cc1plus 24972 larroy20 0 43160 15m 2332 R 76 0.0 0:00.95 cc1plus 24918 larroy20 0 287m 255m 4024 R 70 0.3 0:02.99 cc1plus 24962 larroy20 0 44872 17m 2332 R 69 0.0 0:01.23 cc1plus 24976 larroy20 0 41212 14m 2332 R 66 0.0 0:00.67 cc1plus 24501 larroy20 0 687m 657m 8044 R 64 0.7 0:22.97 cc1plus 24933 larroy20 0 211m 177m 4008 R 62 0.2 0:01.79 cc1plus 24899 larroy20 0 327m 296m 4276 R 57 0.3 0:04.25 cc1plus Are tasks running in per user cgroups or such? If so, you'd need to adjust group shares. -Mike -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Call to atention about using hash functions as content indexers (SCM saga)
Hi I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. And by the way, I've read http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node15.html and I don't agree with it. Asides from the "avalanche effect" the properties of a good hash function is that distributes well the entropy between the output bits, so probably, although the inputs are not random, the pdf change in the outputs would be small, otherwise it would be easier to find collision by differential or statistical methods. Last, hash functions should be only used to check data integrity, and that's the reason of the "avalanche effect", so even single bit errors are propagated and it's effect is very noticeable at the output. Regards. -- Pedro Larroy Tovar | Linux & Network consultant | pedro%larroy.com Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/ * Las patentes de programación son nocivas para la innovación * http://proinnova.hispalinux.es/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Call to atention about using hash functions as content indexers (SCM saga)
Hi I had a quick look at the source of GIT tonight, I'd like to warn you about the use of hash functions as content indexers. As probably you are aware, hash functions such as SHA-1 are surjective not bijective (1-to-1 map), so they have collisions. Here one can argue about the low probability of such a collision, I won't get into subjetive valorations of what probability of collision is tolerable for me and what is not. I my humble opinion, choosing deliberately, as a design decision, a method such as this one, that in some cases could corrupt data in a silent and very hard to detect way, is not very good. One can also argue that the probability of data getting corrupted in the disk, or whatever could be higher than that of the collision, again this is not valid comparison, since the fact that indexing by hash functions without additional checking could make data corruption legal between the reasonable working parameters of the program is very dangerous. And by the way, I've read http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node15.html and I don't agree with it. Asides from the avalanche effect the properties of a good hash function is that distributes well the entropy between the output bits, so probably, although the inputs are not random, the pdf change in the outputs would be small, otherwise it would be easier to find collision by differential or statistical methods. Last, hash functions should be only used to check data integrity, and that's the reason of the avalanche effect, so even single bit errors are propagated and it's effect is very noticeable at the output. Regards. -- Pedro Larroy Tovar | Linux Network consultant | pedro%larroy.com Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/ * Las patentes de programación son nocivas para la innovación * http://proinnova.hispalinux.es/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Vanilla kernel >=2.4.28-rc2 incompatibility with ADSL modem Dlink DSL-G300+
On Sun, Mar 06, 2005 at 06:35:28PM +0100, Alessandro Selli wrote:
> Hello,
> I found a problem having to to with the plain vanilla 2.4.28-rc{2,3} and
> 2.4.29 kernels when I try to use a Dlink DSL-300G+ ethernet ADSL modem
> on a SS5 machine.
>
> The domain "route-add.net" is running on a Sun SparcStation 5 machine,
> equipped with a Micro-SPARCII, 85 MHz processor. This machine has beeing
> running the domain (web, smtp, ssh, imap, telnet, gopher, finger,
> auth/ident, dns) for a year. The machine has two "le" (10 base T)
> ethernet ports, one is connected to the ADSL modem, the other to the LAN.
> The OS is Debian stable (Woody, 3.0).
> The kernel is a plain vanilla one, downloaded from
> ftp.it.kernel.org/pub/linux/kernel/v2.4 with no patches applied to it.
>
> The problem showed up after updating to kernel 2.4.28: the ADSL
> connection would never outlive the fifteenth minute. Even though the
> modem still sensed the ADSL carrier and could be reached into its
> web-based internal control panel over the same ethernet connection that
> served the data exchanged with the ISP, after fifteen minutes it could
> first reach the ISP gateway the connection failed and no packets could
> be neither sent nor received with any host outside the LAN. The
> connection would be available again after a period varying from a few
> minutes to several hours, three quarters of an hour on the average.
> A script that was let running from Jannuary 18th to February 3rd (data
> from Jannuary 29th was lost) produced the following data:
>
> http://route-add.net/ping-noping.txt ("riuscito" = success, "fallito" =
> failed)
> http://route-add.net/ping-noping_18012005-28012005.txt
> http://route-add.net/ping-noping_07012005-17012005.txt ("persa" = lost
> [connection], "tornata" = [coonection is] back)
>
> I tried changing the wiring, I swapped the ethernet ports the LAN and
> ADSL modem where connected to, I swapped the modem with an identical one
> from a colleague of mine, I upgraded to kernel 2.4.29 all to no avail.
> I then tried the 2.4.28-rc{1,2,3} kernels, and I found the 2.4.28-rc1
> not to exhibit the problem, that manifests itself on the 2.4.28-rc{2,3}
> kernels.
> The problem is sparc-specific, a PC with the very same configuration
> (Debian stable, plain vanilla kernels etc.) did not suffer any
> connection drops.
>
> --
> Alessandro Selli
> Tel: 340.839.73.05
> http://alessandro.route-add.net
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I have seen similar problems due to high sequence numbers on the tcp
packets on some adsl routers. Took a while to discover that since the
connection misteriously ceased to work from some boxes after some time
transmitting data ok. Looks like some manufacturers such as efficient
networks adsl routers, doesn't follow the standards.
I'd suggest running tcpdump and doing some observation.
--
Pedro Larroy Tovar | Linux & Network consultant | pedro%larroy.com
Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/
* Las patentes de programación son nocivas para la innovación *
http://proinnova.hispalinux.es/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Vanilla kernel =2.4.28-rc2 incompatibility with ADSL modem Dlink DSL-G300+
On Sun, Mar 06, 2005 at 06:35:28PM +0100, Alessandro Selli wrote:
Hello,
I found a problem having to to with the plain vanilla 2.4.28-rc{2,3} and
2.4.29 kernels when I try to use a Dlink DSL-300G+ ethernet ADSL modem
on a SS5 machine.
The domain route-add.net is running on a Sun SparcStation 5 machine,
equipped with a Micro-SPARCII, 85 MHz processor. This machine has beeing
running the domain (web, smtp, ssh, imap, telnet, gopher, finger,
auth/ident, dns) for a year. The machine has two le (10 base T)
ethernet ports, one is connected to the ADSL modem, the other to the LAN.
The OS is Debian stable (Woody, 3.0).
The kernel is a plain vanilla one, downloaded from
ftp.it.kernel.org/pub/linux/kernel/v2.4 with no patches applied to it.
The problem showed up after updating to kernel 2.4.28: the ADSL
connection would never outlive the fifteenth minute. Even though the
modem still sensed the ADSL carrier and could be reached into its
web-based internal control panel over the same ethernet connection that
served the data exchanged with the ISP, after fifteen minutes it could
first reach the ISP gateway the connection failed and no packets could
be neither sent nor received with any host outside the LAN. The
connection would be available again after a period varying from a few
minutes to several hours, three quarters of an hour on the average.
A script that was let running from Jannuary 18th to February 3rd (data
from Jannuary 29th was lost) produced the following data:
http://route-add.net/ping-noping.txt (riuscito = success, fallito =
failed)
http://route-add.net/ping-noping_18012005-28012005.txt
http://route-add.net/ping-noping_07012005-17012005.txt (persa = lost
[connection], tornata = [coonection is] back)
I tried changing the wiring, I swapped the ethernet ports the LAN and
ADSL modem where connected to, I swapped the modem with an identical one
from a colleague of mine, I upgraded to kernel 2.4.29 all to no avail.
I then tried the 2.4.28-rc{1,2,3} kernels, and I found the 2.4.28-rc1
not to exhibit the problem, that manifests itself on the 2.4.28-rc{2,3}
kernels.
The problem is sparc-specific, a PC with the very same configuration
(Debian stable, plain vanilla kernels etc.) did not suffer any
connection drops.
--
Alessandro Selli
Tel: 340.839.73.05
http://alessandro.route-add.net
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I have seen similar problems due to high sequence numbers on the tcp
packets on some adsl routers. Took a while to discover that since the
connection misteriously ceased to work from some boxes after some time
transmitting data ok. Looks like some manufacturers such as efficient
networks adsl routers, doesn't follow the standards.
I'd suggest running tcpdump and doing some observation.
--
Pedro Larroy Tovar | Linux Network consultant | pedro%larroy.com
Make debian mirrors with debian-multimirror: http://pedro.larroy.com/deb_mm/
* Las patentes de programación son nocivas para la innovación *
http://proinnova.hispalinux.es/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
