| 12:14 | rabeeh | Flooo: ping |
| 12:15 | koboldmaki | good morning |
| 12:15 | rabeeh | good morning |
| 12:17 | koboldmaki | i made some speedtest for the cubox, e.g. network, and it ranges between 720MBit to 1.2 Gb |
| 12:18 | rabeeh | 1.2Gb? |
| 12:18 | rabeeh | The link is max 1Gbps |
| 12:19 | koboldmaki | yes, I know, I tested over the "local" interface with iperf |
| 12:20 | rabeeh | aah |
| 12:21 | koboldmaki | and it shows me the "bandwith" on the machine |
| 12:22 | koboldmaki | the speed e.g. iperf, mac -> fritz -> cubox was [ 5] 0.0-10.0 sec 430 MBytes 361 Mbits/sec, the bootleneck was the fritz.box (7390) |
| 12:24 | dxtr | I just got my cubox the other day \o |
| 12:24 | dxtr | It's pretty cool |
| 12:24 | koboldmaki | iperf with archlinux, iperf -> cubox -> cubox (same), [ 3] 0.0-10.0 sec 1.29 GBytes 1.11 Gbits/sec (not the 1.2 Gb, sorry) |
| 12:25 | rabeeh | koboldmaki: try switching iperf that CuBox would be the client |
| 12:25 | rabeeh | when the main workload on CuBox is sending, it's much more faster than receiving |
| 12:25 | koboldmaki | and with a crossover cabel, iperf, cubox -> mac, [ 4] 0.0-10.0 sec 599 MBytes 503 Mbits/sec |
| 12:25 | rabeeh | the reason is because TCP hardware offload engines are better on sending than receiving. |
| 12:26 | rabeeh | iperf try switching those |
| 12:26 | koboldmaki | ok. |
| 12:27 | koboldmaki | in a last post, there was the discussion it the cubox should will have 2 GB in the next version, I vote for a "YES", you could reach the limit if you compile the kernel with "make -j" -> BANG... welcome oom-killer |
| 12:28 | koboldmaki | what about "more cpus" in the cubox and some gpio s? |
| 12:29 | rabeeh | ? |
| 12:31 | koboldmaki | the cubox has only 1 CPU, will there be a version with 2 CPUs? |
| 12:31 | rabeeh | koboldmaki: i can't disclose roadmap. yet. |
| 12:31 | koboldmaki | ok. |
| 12:32 | rabeeh | for the oom-killer; try booting a kernel without the GPU and Video engine; so you can potentially use the whole 1GB |
| 12:32 | rabeeh | for the 2GB; we have the hardware but still not working |
| 12:32 | koboldmaki | root@kob-cubox:/etc/nagios-nrpe# free -m total used free shared buffers cached Mem: 1008 346 662 0 11 277 -/+ buffers/cache: 56 952 Swap: 0 0 0 |
| 12:33 | koboldmaki | 1 GB RAM, no memory for the gpu.. |
| 12:33 | rabeeh | so maybe add some swap? or work without X? |
| 12:33 | koboldmaki | and the oom-killer arives... ok, should enable a swap-file... |
| 12:34 | koboldmaki | yes no X.. only text/plain ;-) |
| 12:34 | rabeeh | for swap please don't add on the micro-SD; try a non solid state memory |
| 12:34 | rabeeh | swap on solid state kills it in few months |
| 12:34 | koboldmaki | yes, I knew this |
| 12:35 | rabeeh | welcome back dotarray |
| 12:35 | rabeeh | (and Pnukley_Chilling) |
| 12:36 | dotarray | thank you rabeeh! :) |
| 12:36 | Punkley_Chillin | im so tired... |
| 12:42 | koboldmaki | in the kernel tree, when will the options for "cubox" available? From kernel 3.7.x? |
| 12:42 | koboldmaki | kernel, I mean the vanilla version |
| 13:14 | purch | has there been problems with doing do-release-upgrade on lucid box? |
| 13:16 | purch | maybe take an image of the ssd first for quick restore if something happens? |
| 15:01 | koboldmaki | when will the kernel configuration options for the "cubox" available in the vanilla tree? |
| 15:08 | rabeeh | koboldmaki: vanilla tree still doesn't support CuBox. |
| 15:08 | rabeeh | there is partial Dove (main processor) support but still far from complete |
| 15:09 | koboldmaki | ok. |
| 15:19 | rabeeh | koboldmaki: ofcourse every kerenl upstreaming help is welcomed |
| 18:15 | Flooo | re |
| 18:46 | Flooo | im off now.. bye |
| 19:00 | neofob | a screenshot of my gluster healing powered by two cuboxes (Marvell Armada 510 @ 800Mhz) http://bit.ly/QNQX1u |
| 19:23 | rabeeh | neofob: nice :) |
| 19:23 | rabeeh | why do you need more processing power in healing stage? |
| 19:23 | rabeeh | what is the process of doing gluster healing? |
| 19:34 | neofob | @ rabeeh: my suspection is that gluster uses some cpu power for hashing calculation |
| 19:36 | neofob | i'd love to have a bit faster CuBox; an implementation of quad-core A9 or something will be great for non-graphics apps like this |
| 19:37 | neofob | what i like about CuBox is that it has esata and gigabit ethernet unlike many ARM boards out there |
| 19:38 | neofob | on the esata note; you guys need to make the esata port a bit more sturdy |
| 19:38 | rabeeh | i'v noticed that you have reached 103MB/sec? |
| 19:39 | rabeeh | that's the max speed on one direction of gigabit ethernet link |
| 19:39 | rabeeh | oh; you had to enable jumbo frames for that. |
| 19:40 | neofob | yep, that's why i found your lost patch in 2.6.39 |
| 19:40 | neofob | please add it in your 3.5 branch :D |
| 19:40 | rabeeh | ok |
| 19:41 | rabeeh | few patches actually missing. |
| 19:56 | rabeeh | jnettlet: where can I find your FB KMS driver? |
| 19:56 | rabeeh | i mean the kernel part |