All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <4821D059.7020808@matrix-vision.de>

diff --git a/a/1.txt b/N1/1.txt
index 53ba2df..f8ad5b6 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,26 +1,26 @@
 Anton,
 
-we've just built a digital GigEVision camera based on a MPC8343 running=20
+we've just built a digital GigEVision camera based on a MPC8343 running 
 at 266/400 csb/core speed.
 
-Transmission is done from a kernel module that allocates skb into which=20
+Transmission is done from a kernel module that allocates skb into which 
 the image data is DMA'd by an external PCI master.
-As soon as the image data is complete all buffers are sent out via=20
+As soon as the image data is complete all buffers are sent out via 
 dev->hard_start_xmit ...
 
-Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec=20
+Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec 
 (~520MBit/s).
 Of course it's UDP _without_ checksumming ....
 
-Actually I have no sensor available that gives higher bandwidth ... but=20
-having a look at transmission time I'm sure the MPC8343 can easily go up=20
+Actually I have no sensor available that gives higher bandwidth ... but 
+having a look at transmission time I'm sure the MPC8343 can easily go up 
 to +800MBit.
 
 
 Obviously your cpu time is consumed on a higher level.
 
 Cheers,
-Andr=E9
+André
 
 
 Anton Vorontsov wrote:
@@ -35,8 +35,7 @@ Anton Vorontsov wrote:
 > The maximum value I've seen with the current kernels is 142 Mb/s of TCP
 > and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):
 >
->   root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157=
-344 -S 157344
+>   root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
 >   TCP STREAM TEST to 10.0.1.1
 >   #Cpu utilization 0.10
 >   Recv   Send    Send
@@ -46,8 +45,7 @@ Anton Vorontsov wrote:
 >
 >   206848 212992  32768    10.00     142.40
 >
->   root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157=
-344 -S 157344
+>   root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344
 >   UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1
 >   #Cpu utilization 100.00
 >   Socket  Message  Elapsed      Messages
@@ -62,8 +60,7 @@ Anton Vorontsov wrote:
 >
 > netperf running in loopback gives me 329 Mb/s of TCP throughput:
 >
->   root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 15=
-7344 -S 157344
+>   root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
 >   TCP STREAM TEST to 127.0.0.1
 >   #Cpu utilization 100.00
 >   #Cpu utilization 100.00
@@ -79,10 +76,8 @@ Anton Vorontsov wrote:
 > theoretical maximum for this setup? Or this isn't reliable test?
 >
 >
-> I can compare with teh MPC8377E-RDB (very similar board - exactly the s=
-ame
-> ethernet phy, the same drivers are used, i.e. everything is the same fr=
-om
+> I can compare with teh MPC8377E-RDB (very similar board - exactly the same
+> ethernet phy, the same drivers are used, i.e. everything is the same from
 > the ethernet stand point), but running at 666 MHz, CSB at 333MHz:
 >
 >          |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|
@@ -103,13 +98,13 @@ om
 > +++ b/drivers/net/gianfar.h
 > @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];
 >  #define GFAR_10_TIME    25600
-> =20
+>  
 >  #define DEFAULT_TX_COALESCE 1
 > -#define DEFAULT_TXCOUNT	16
 > -#define DEFAULT_TXTIME	21
 > +#define DEFAULT_TXCOUNT	80
 > +#define DEFAULT_TXTIME	105
-> =20
+>  
 >  #define DEFAULT_RXTIME	21
 >
 >
@@ -117,8 +112,7 @@ om
 > it more didn't help, as well as didn't help raising rx thresholds).
 > Now:
 >
-> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344=
- -S 157344
+> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344
 > TCP STREAM TEST to 10.0.1.1
 > #Cpu utilization 100.00
 > Recv   Send    Send
@@ -137,13 +131,13 @@ om
 >
 > --- 10.0.1.1 ping statistics ---
 > 20 packets transmitted, 20 received, 0% packet loss, time 18997ms
-> rtt min/avg/max/mdev =3D 0.108/0.124/0.173/0.022 ms
+> rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms
 >
 > After:
 >
 > --- 10.0.1.1 ping statistics ---
 > 22 packets transmitted, 22 received, 0% packet loss, time 20997ms
-> rtt min/avg/max/mdev =3D 0.158/0.167/0.182/0.004 ms
+> rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms
 >
 >
 > 34% up... heh. Should we sacrifice the latency in favour of throughput?
@@ -157,9 +151,8 @@ om
 > since on the -rt kernels the throughput is near 100 Mb/s, with the
 > patch the throughput is close to 140 Mb/s.
 >
->  =20
+>   
 
 
-MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=
-ht: Amtsgericht Stuttgart, HRB 271090
-Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
+MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
+Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
diff --git a/a/content_digest b/N1/content_digest
index 370e5f0..6cc7675 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -9,27 +9,27 @@
  "b\0"
  "Anton,\n"
  "\n"
- "we've just built a digital GigEVision camera based on a MPC8343 running=20\n"
+ "we've just built a digital GigEVision camera based on a MPC8343 running \n"
  "at 266/400 csb/core speed.\n"
  "\n"
- "Transmission is done from a kernel module that allocates skb into which=20\n"
+ "Transmission is done from a kernel module that allocates skb into which \n"
  "the image data is DMA'd by an external PCI master.\n"
- "As soon as the image data is complete all buffers are sent out via=20\n"
+ "As soon as the image data is complete all buffers are sent out via \n"
  "dev->hard_start_xmit ...\n"
  "\n"
- "Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec=20\n"
+ "Bandwidth is currently 1.3MPixel @ 50Hz which give 65MBytes/sec \n"
  "(~520MBit/s).\n"
  "Of course it's UDP _without_ checksumming ....\n"
  "\n"
- "Actually I have no sensor available that gives higher bandwidth ... but=20\n"
- "having a look at transmission time I'm sure the MPC8343 can easily go up=20\n"
+ "Actually I have no sensor available that gives higher bandwidth ... but \n"
+ "having a look at transmission time I'm sure the MPC8343 can easily go up \n"
  "to +800MBit.\n"
  "\n"
  "\n"
  "Obviously your cpu time is consumed on a higher level.\n"
  "\n"
  "Cheers,\n"
- "Andr=E9\n"
+ "Andr\303\251\n"
  "\n"
  "\n"
  "Anton Vorontsov wrote:\n"
@@ -44,8 +44,7 @@
  "> The maximum value I've seen with the current kernels is 142 Mb/s of TCP\n"
  "> and 354 Mb/s of UDP (NAPI and interrupts coalescing enabled):\n"
  ">\n"
- ">   root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157=\n"
- "344 -S 157344\n"
+ ">   root@b1:~# netperf -l 10 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344\n"
  ">   TCP STREAM TEST to 10.0.1.1\n"
  ">   #Cpu utilization 0.10\n"
  ">   Recv   Send    Send\n"
@@ -55,8 +54,7 @@
  ">\n"
  ">   206848 212992  32768    10.00     142.40\n"
  ">\n"
- ">   root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157=\n"
- "344 -S 157344\n"
+ ">   root@b1:~# netperf -l 10 -H 10.0.1.1 -t UDP_STREAM -- -m 32768 -s 157344 -S 157344\n"
  ">   UDP UNIDIRECTIONAL SEND TEST to 10.0.1.1\n"
  ">   #Cpu utilization 100.00\n"
  ">   Socket  Message  Elapsed      Messages\n"
@@ -71,8 +69,7 @@
  ">\n"
  "> netperf running in loopback gives me 329 Mb/s of TCP throughput:\n"
  ">\n"
- ">   root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 15=\n"
- "7344 -S 157344\n"
+ ">   root@b1:~# netperf -l 10 -H 127.0.0.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344\n"
  ">   TCP STREAM TEST to 127.0.0.1\n"
  ">   #Cpu utilization 100.00\n"
  ">   #Cpu utilization 100.00\n"
@@ -88,10 +85,8 @@
  "> theoretical maximum for this setup? Or this isn't reliable test?\n"
  ">\n"
  ">\n"
- "> I can compare with teh MPC8377E-RDB (very similar board - exactly the s=\n"
- "ame\n"
- "> ethernet phy, the same drivers are used, i.e. everything is the same fr=\n"
- "om\n"
+ "> I can compare with teh MPC8377E-RDB (very similar board - exactly the same\n"
+ "> ethernet phy, the same drivers are used, i.e. everything is the same from\n"
  "> the ethernet stand point), but running at 666 MHz, CSB at 333MHz:\n"
  ">\n"
  ">          |CPU MHz|BUS MHz|UDP Mb/s|TCP Mb/s|\n"
@@ -112,13 +107,13 @@
  "> +++ b/drivers/net/gianfar.h\n"
  "> @@ -123,8 +123,8 @@ extern const char gfar_driver_version[];\n"
  ">  #define GFAR_10_TIME    25600\n"
- "> =20\n"
+ ">  \n"
  ">  #define DEFAULT_TX_COALESCE 1\n"
  "> -#define DEFAULT_TXCOUNT\t16\n"
  "> -#define DEFAULT_TXTIME\t21\n"
  "> +#define DEFAULT_TXCOUNT\t80\n"
  "> +#define DEFAULT_TXTIME\t105\n"
- "> =20\n"
+ ">  \n"
  ">  #define DEFAULT_RXTIME\t21\n"
  ">\n"
  ">\n"
@@ -126,8 +121,7 @@
  "> it more didn't help, as well as didn't help raising rx thresholds).\n"
  "> Now:\n"
  ">\n"
- "> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344=\n"
- " -S 157344\n"
+ "> root@b1:~# netperf -l 3 -H 10.0.1.1 -t TCP_STREAM -- -m 32768 -s 157344 -S 157344\n"
  "> TCP STREAM TEST to 10.0.1.1\n"
  "> #Cpu utilization 100.00\n"
  "> Recv   Send    Send\n"
@@ -146,13 +140,13 @@
  ">\n"
  "> --- 10.0.1.1 ping statistics ---\n"
  "> 20 packets transmitted, 20 received, 0% packet loss, time 18997ms\n"
- "> rtt min/avg/max/mdev =3D 0.108/0.124/0.173/0.022 ms\n"
+ "> rtt min/avg/max/mdev = 0.108/0.124/0.173/0.022 ms\n"
  ">\n"
  "> After:\n"
  ">\n"
  "> --- 10.0.1.1 ping statistics ---\n"
  "> 22 packets transmitted, 22 received, 0% packet loss, time 20997ms\n"
- "> rtt min/avg/max/mdev =3D 0.158/0.167/0.182/0.004 ms\n"
+ "> rtt min/avg/max/mdev = 0.158/0.167/0.182/0.004 ms\n"
  ">\n"
  ">\n"
  "> 34% up... heh. Should we sacrifice the latency in favour of throughput?\n"
@@ -166,11 +160,10 @@
  "> since on the -rt kernels the throughput is near 100 Mb/s, with the\n"
  "> patch the throughput is close to 140 Mb/s.\n"
  ">\n"
- ">  =20\n"
+ ">   \n"
  "\n"
  "\n"
- "MATRIX VISION GmbH, Talstra=DFe 16, DE-71570 Oppenweiler  - Registergeric=\n"
- "ht: Amtsgericht Stuttgart, HRB 271090\n"
- Gesch=E4ftsf=FChrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
+ "MATRIX VISION GmbH, Talstra\303\237e 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090\n"
+ "Gesch\303\244ftsf\303\274hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner"
 
-72b2e2fa152b6803f014c84c13158a03f38738eba2257f4bbc173efc90095ce3
+1dc51c59a14f0023450c4ec7f21c00cc6ad21c7a1eff2e02d3679d29b5005a53

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.