05:51 | BlinkyBill | is there a reference somewhere that describes the pros and cons of each installation OS/package? I'm looking for headless, but don't know betwen deb and ubuntu |
08:58 | jnettlet | _dab_, so do you want the bad news? |
09:06 | cbxbiker61 | i'm getting iperf 436 Mbit/sec with 3.10.38 as a client, that's fine for my purposes |
09:07 | cbxbiker61 | original cubox does 716 Mbit/sec |
09:07 | jnettlet | cbxbiker61, transmit or receive? |
09:08 | cbxbiker61 | ran iperf -c to linux server |
09:08 | jnettlet | yeah so transmit. That is about right. Receive with the new fec driver by rmk will do about 550-600Mbps |
09:12 | _dab_ | give me the bad news |
09:16 | jnettlet | _dab_, well without access to the failed hardware we probably can't fully diagnose this...meaning failed hardware that also supports an open distro. |
09:16 | jnettlet | but beyond that to get any sort of performance with the mx6 you really need hardware that supports flow control. |
09:18 | jnettlet | the reason being that the bus limitation on the iMX6 can't handle gigabit line speed so there needs to be some way to tell the sender to slow down while the CBi handles the incoming packets. |
09:18 | jnettlet | that is why transmit isn't effected. |
09:19 | jnettlet | TCP's methods aren't sufficient because it starts out sending data at gigabit speeds and very quickly you are doing the transmission dance of which packets are dropped because the CBi can only handle half of the data. |
09:19 | _dab_ | I tried to hack the device, with no luck. Hard to tell if it is just capacity or flow control that allows it to work with 20 or so other devices. |
09:20 | jnettlet | _dab_, does the hardware manufacturer claim to support flow control? |
09:20 | _dab_ | yes |
09:21 | _dab_ | I hassled them (a lot) and their response was similar to rms. "Get hardware that supports flow control" |
09:21 | _dab_ | rms=rmks |
09:22 | jnettlet | but the iMX6 does support flow control |
09:23 | jnettlet | the only way to really figure out what is going on is analyzing the ethernet frames |
09:23 | _dab_ | hmm |
09:25 | _dab_ | The problem is really a sales problem. Buy a cubox-i and you might need a new router/switch |
09:28 | _dab_ | It takes out the idea of using cubox-i as a consumer device. One has no control over what switches the average home user might have. |
09:29 | cbxbiker61 | i would disagree with that, when you speak of consumer what you are saying is cheap....and you can't necessarily count on top performance when everything is cheap |
09:30 | cbxbiker61 | most "consumers" will never know the difference |
09:30 | jnettlet | for most consumers 100Mbs is way more than enough. Especially since most will use wifi that really maxes out at about 20Mbs |
09:31 | _dab_ | yeah biker, I agree. I have a telco who is using sheevaplugs as consumer device(no idea what for) and they have told me that they won't consider cubox-i unless I can give them at least 300MBit |
09:32 | _dab_ | In every other way cubox-i is so much nicer than the sheevas |
09:35 | _dab_ | cbxbiker61: if you still have a cubox as a router, would you be interested in sharing you iptables? |
09:37 | cbxbiker61 | well the router's iptables is pretty specific to this install, but i do have a pretty good generic script for workstations |
09:37 | cbxbiker61 | it uses ipset with iptables to make custom configs relatively easy |
09:40 | _dab_ | Want to give me a link? And has the cubox served ok as the router/fw? I was thinking of net->cubox->switch->wifiap |
09:40 | cbxbiker61 | it does both ipv4 and ipv6 with common functionality |
09:40 | _dab_ | cool |
09:42 | cbxbiker61 | _dab_, yeah you really can't tell the difference between that and big iron, unless you're using a hell of a lot of bandwidth |
09:45 | cbxbiker61 | http://www.xilka.com/xilka/source/firewall.sh |
09:45 | _dab_ | thanking you |
09:45 | cbxbiker61 | create a firewall config file in /etc/conf.d with pertinent entries |
09:47 | _dab_ | I like the script |
09:48 | cbxbiker61 | thanks |
09:53 | _dab_ | Anything special in the .config for the cubox router? |
09:54 | _dab_ | kernel wise |
09:55 | cbxbiker61 | yeah, well you want to turn on all of the matching code as modules, anything that is referenced will get loaded |
09:57 | cbxbiker61 | if you're doing a firewall config, you should also enable the stuff to do qos, since you may get to use that at some point |
09:58 | cbxbiker61 | i've got qos working great, although i've been tweeking my config for 2 or 3 years |
09:58 | Coolg33k | cbxbiker61: for your router, do you use 2 network adapter ? |
09:59 | _dab_ | I will give it ago, seems like a good use for a first edition cubox |
09:59 | cbxbiker61 | yeah, just a well supported usb adapter works fine |
10:01 | cbxbiker61 | i had a dual-nic i686 before i swapped out, and i think the usb adapter added about 1ms to the ping time, for all practical purposes no difference |
10:04 | cbxbiker61 | _dab_, unless your doing something special, just use the kernels for cubox on xilka.com, they're all set for a router |
10:11 | _dab_ | cbxbiker61: I will |
10:11 | dz0ny | _dab_ i would recommend fireqos an firehol for firewall setup |
18:59 | msalerno | Has anyone gotten vivante_drv.o to compile in 3.14? |
18:59 | msalerno | linux |
23:02 | msalerno | Has anyone gotten vivante_drv.o to compile in 3.14? |