| 01:34.21 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 02:38.14 | *** join/#arm-netbook CaCtus491 (~Kent@123-243-197-152.static.tpgi.com.au) |
| 02:42.08 | ManoftheSea | Like the N900? |
| 02:46.08 | *** join/#arm-netbook hipboi (~hipboi@221.4.213.95) |
| 12:19.58 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 13:21.15 | mnemoc | the n900 gives you a normal desktop when docking it?? |
| 13:26.37 | A2Sheds | "plus the added features of a buggy kernel, backported drivers, a file directory structure that no other Linux distro follows, nearly every package has been renamed "just because", buggy bullet proof X and network manager, etc etc" :) |
| 13:27.57 | A2Sheds | or are those features for x86 only? |
| 13:33.36 | mnemoc | :) |
| 13:40.49 | *** join/#arm-netbook A2Sheds (~ly@unaffiliated/l84supper) |
| 14:18.26 | *** join/#arm-netbook A2Sheds (~ly@unaffiliated/l84supper) |
| 14:58.29 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 15:03.14 | *** join/#arm-netbook mul (~mul@unaffiliated/mul) |
| 16:50.03 | *** join/#arm-netbook gordan (~gordan@31.97.212.141) |
| 20:28.07 | *** join/#arm-netbook gordan (~gordan@78-86-195-86.zone2.bethere.co.uk) |
| 21:29.39 | *** join/#arm-netbook moocow (~moocow100@cpc2-nmal13-0-0-cust500.croy.cable.virginmedia.com) |
| 21:33.13 | moocow | Hi, bit of a newbie ARM and linux wise and wondering if there is a storage boot order .. by that i mean if i take a nand booting device and put the relevant boot files (plus kernel and distro) on the sd card or usb stick will the a10 device then boot from the sd rather than the nand (and merely taking out the sd card or usb stick would revert then back to nand boot) ...thx |
| 21:35.26 | *** part/#arm-netbook moocow (~moocow100@cpc2-nmal13-0-0-cust500.croy.cable.virginmedia.com) |
| 21:35.34 | Gumboot | types too slowly |
| 22:11.25 | *** join/#arm-netbook frafra (~frafra@net-93-150-108-234.cust.dsl.teletu.it) |
| 22:11.28 | frafra | hi all |
| 22:14.30 | frafra | I have some question about a10 soc |
| 22:14.37 | frafra | *questions |
| 22:15.43 | frafra | can I write them? |
| 22:16.54 | gordan | frafra - you may want to try the mailing list - there is a high chance that the people who know the answers here won't be checking the archive logs (if there are any). |
| 22:18.40 | frafra | thanks gordan, I'm reading the mailing list from november, but my questions are so simple, nothing very technical :) |
| 22:19.53 | gordan | Yes, but if there's nobody here right now that can answer them, the chances are they'll get missed. :) |
| 22:20.13 | gordan | This is not exactly a high-bandwidth channel. :) |
| 22:20.56 | frafra | so... I'll write them here, I've one hour now. If nobody reply to me, I'll make my noob question on the ml :D |
| 22:22.29 | frafra | a) at stage alpha, what you get? an eoma card powered by usb? this factor is quite tiny, so where there will be the usb port? |
| 22:23.04 | gordan | IIRC there'll be a micro-USB port on it. |
| 22:23.21 | frafra | b) at beta stage, what there will be? what do you mean for motherboard? I know what it is, but do you think to do a board and plug many eoma soc? |
| 22:23.32 | gordan | If you check the ML archives, I'm sure somebody posted a picture of the back of the card with the relevant connectors. |
| 22:23.50 | frafra | thanks |
| 22:24.42 | gordan | Last time I spoke to Luke about this, he said the basic "motherboard" (basically a break-out board for all the other stuff) will be available imminently after the alphas ship. |
| 22:25.10 | gordan | But yes, the plan is to make it into a modular architecture. |
| 22:26.04 | gordan | So that you can have multiple devices that take an EOMA CPU board (laptop, set top box, TV, desktop PC, etc.) |
| 22:26.51 | frafra | ok, so we have some ports (like the usb one) on the eoma and then we'll get an entire modular computer, which sees those eoma cards as one entity? |
| 22:27.25 | gordan | And conversely, that when a new SoC comes out that has better performance or price/performance or lower power consumption or whatever other valuable advantage, we make a new EOMA module that plugs into whatever existing EOMA "mother" device is already in place, and it'll "just work". |
| 22:27.59 | gordan | Basically, the rest of the device is more or less just a break-out board, all the core stuff is on the EOMA card. |
| 22:28.43 | gordan | It means you could take your EOMA card from your desktop PC at home and put it in your laptop, use it on the way to work, then plug it into your desktop PC at work when you get there. |
| 22:29.18 | frafra | ok, so I have one operating system for one eoma card? |
| 22:29.28 | gordan | And it'd be like taking the whole machine with all of it's configuration, data and "personality" along. |
| 22:29.52 | gordan | Well, the OS can be anything that'll run on the SoC, typically Linux. |
| 22:30.37 | gordan | Not sure what you are referring to with the one-to-one relationship regarding the OS. |
| 22:31.19 | frafra | I'm thinking about this situation: what about a nas, using this structure? if every eoma card acts as a separated computer, I have to use a clustered filesystem, right? |
| 22:31.52 | frafra | (I mean when I use them with a motherboard) |
| 22:36.45 | frafra | if I've a motherboard with N eoma cards, I have N sata ports and N operating system, so I've to share theirs data using ethernet, right? |
| 22:37.45 | frafra | if the system acts as one, my only os could see N sata ports and reads whatever it wants |
| 22:38.27 | frafra | I don't understand if the motherboard is only for power stuff or it allows to use an unified system |
| 22:44.27 | frafra | sorry, I've a bad connection here, I didn't read anything after gordan "Not sure what [...]" response. If someone has replied to me, please resend the message in pvt |
| 22:44.46 | gordan | Hmm... |
| 22:45.03 | gordan | NAS vs. cluster are two totally distinct use-cases. |
| 22:45.50 | gordan | There is no reason you couldn't plug an EOMA into a NAS shell, and use it to drive a NAS box, but you'd be limited in terms of SATA ports (there is at least one, but that may be all you get). |
| 22:46.50 | gordan | Clustering, sure, a use case that is important to me personally is, say, a 2U chassis that takes a big pile of EOMA cards so I can have a really dense blade server for build farms, and such like. There is no reason you couldn't set up some kind of a cluster on these. |
| 22:47.35 | gordan | I believe this describes your case with many EOMA cards. And yes, the obvious inter-machine interconnect to use is ethernet in that case. |
| 22:47.48 | frafra | ok, thanks so much gordan |
| 22:48.06 | frafra | so the motherboard in this case give only the power, right? |
| 22:48.08 | gordan | The system will NOT act as one. Well, not unless your OS specifically has a feature for that. |
| 22:48.25 | frafra | ok, now it's clear, thanks |
| 22:49.04 | gordan | It gives power, and provides a break-out for other things, e.g. SATA so you can have SATA disks in the chassis. You can then either share that disk over NFS with all the nodes in the chassis (or outside the chassis even), or you can have one SATA disk per node. |
| 22:49.49 | gordan | There is positively nothing special about the EOMA cards in terms of distinction from any computer other than that they are very low power and cheap. |
| 22:49.54 | gordan | And easily swappable. |
| 22:50.37 | gordan | If you are pipe dreaming about magically making many machines appear as one machine - sorry to disappoint you - that is a software feature. :) |
| 22:51.03 | frafra | how the eoma cards can see a sata disk connected to the motherboard? the motherboard gives the control to a special card? |
| 22:51.27 | lkcl | frafra: it's just wires. |
| 22:51.55 | frafra | hi lkcl |
| 22:51.56 | lkcl | the SATA wires go through the EOMA-68 connector, and from there it is up to the I/O Board Designer to decide what to do. |
| 22:51.58 | lkcl | hallo |
| 22:52.01 | frafra | thanks |
| 22:52.11 | lkcl | so, some cases, the I/O Board will have an eSATA connector |
| 22:52.18 | gordan | As I said - any motherboard is just a break-out board. |
| 22:52.22 | lkcl | other cases, an internal SATA (for 3.5 and 2.5in SATA drives) |
| 22:52.25 | lkcl | basically, yeah. |
| 22:52.45 | frafra | thank you so much |
| 22:52.58 | gordan | You may want to look at projects such as Kerrighed: http://kerrighed.org/wiki/index.php/Main_Page |
| 22:53.01 | frafra | I'll change my order, I'll get also an alpha board :) |
| 22:53.01 | lkcl | gordan: we're kinda using the term "I/O Board" because motherboard implies that it's restricted to Desktop PC designs and concepts |
| 22:53.15 | frafra | kerrighed doesn't run on arm, right? |
| 22:53.17 | lkcl | also, someone could put down one of those SATA "splitter" ICs |
| 22:53.25 | lkcl | so you could have up to 15 SATA devices. |
| 22:53.36 | gordan | I think you are referring to a "SATA port replicator". :) |
| 22:53.46 | lkcl | but that is all *entirely* up to the chassis / I/O Board designer |
| 22:53.58 | gordan | The performance may suck, depending on how the host SATA is implemented. |
| 22:54.00 | lkcl | something like that, probably, yeah he he |
| 22:54.07 | Gumboot | Presumably you could get such a thing as a raid controller that presented a SATA interface to the CPU. |
| 22:54.23 | gordan | You used to be able to. |
| 22:54.25 | lkcl | Gumboot: yes - etc. etc. |
| 22:54.25 | gordan | Not any more. |
| 22:54.30 | lkcl | oh? |
| 22:54.31 | lkcl | ah well |
| 22:54.53 | Gumboot | I think I need to channel-hop less, too. |
| 22:55.16 | gordan | You used to be able to get a "box" the size of approximately a 5.25" disk, that had multiple IDE connectors and would take a bunch of IDE drives, RAID them up, and present them as one IDE or SCSI disk. |
| 22:55.34 | gordan | But last time I saw such a thing was 12 years ago. |
| 22:55.42 | gordan | Now days, it's all based on port replication. |
| 22:56.05 | frafra | lkcl, when do you think the alpha boards could be released? |
| 22:56.33 | gordan | frafra: Kerrighed will virtually glue multiple distinct machines together into one bigger logical machine. But there are limitations in terms of what can be migrated and what will benefit. |
| 22:56.56 | lkcl | when they're ready, frafra |
| 22:57.12 | frafra | gordan, I know what it could do, but it doesn't support arm I've seen :( |
| 22:57.27 | gordan | Indeed, at the moment it is x86-64 only. |
| 22:57.29 | frafra | lkcl, you like debian right? :D |
| 22:57.32 | lkcl | yyep. |
| 22:57.42 | lkcl | and openembedded. |
| 22:57.49 | lkcl | each for different purposes. |
| 22:57.49 | gordan | There are other similar things, though, with different limitations. |
| 22:58.06 | Gumboot | boggles at how much work-related stuff he's seeing floating by on IRC right now. |
| 22:58.10 | gordan | Re: SATA replicators/multipliers, this is what I was talking about: http://www.siliconimage.com/products/category.aspx?cid=25&fid=3 |
| 22:58.29 | lkcl | Gumboot: *lol* |
| 22:58.38 | gordan | Sil3826 will give you 5 ports out of 1. |
| 22:59.13 | gordan | Whether performance will suck depends on whether the A10 SATA supports FIS. |
| 22:59.55 | gordan | Basically whether it knows how to "tag" comms streams (like a VLAN on an ethernet switch), or whether it has to do manual switching. |
| 23:00.07 | Gumboot | A few days ago I noticed some useful chatter in one of the channels I log while I was looking for something else, and so I set a bunch of word alerts on work-related terms. Now I'm getting flooded with useful but unstructured information. |
| 23:00.14 | Gumboot | .. there it goes again |
| 23:00.15 | Gumboot | hops away |
| 23:00.16 | gordan | In the latter case, your aggregate performance will go down as you add more disks, rather than increase. |
| 23:01.09 | gordan | And frafra - virtual aggregation like Kerrighed is actually rather over-rated. |
| 23:01.23 | gordan | Sure, it sounds sexy at a glance, but in reality, there is almost always a better way to do things. |
| 23:01.57 | Gumboot | gordan: Keep talking! |
| 23:02.12 | gordan | Handling operation on a distributed system at application level is the way forward. |
| 23:02.44 | gordan | Gumboot: Not much more to say on the subject. :) |
| 23:03.00 | Gumboot | Oh. |
| 23:03.13 | Gumboot | I just want names of systems so I have things to investigate. |
| 23:03.31 | frafra | gordan, sure :) |
| 23:03.33 | gordan | I could go off on some wild tangent, but it's getting late and I have to be up in about 7 hours. :p |
| 23:03.40 | Gumboot | Hm. Me too. |
| 23:03.46 | gordan | Gumboot, names of what systems? |
| 23:03.53 | gordan | You mean things like Kerrighed? |
| 23:04.01 | gordan | Mosix/OpenMosix come to mind. |
| 23:04.15 | frafra | but really, no timeline about this project? |
| 23:04.59 | gordan | Gumboot: You may find this page handy: http://openssi.org/cgi-bin/view?page=openssi.html |
| 23:05.17 | gordan | The term used for this sort of stuff is "Single System Image". |
| 23:05.58 | gordan | I dabbled in it at some length in the past, but the suitability of it for use as a replacement for decent application design is purely illusory. |
| 23:06.44 | Gumboot | I'm actually looking for points where software can be made to view other processors in the same SoC as being more remote than they really are, for the sake of getting greater control over the intercommunication. |
| 23:07.05 | gordan | For what reason? |
| 23:07.27 | gordan | If your use case is using legacy apps, you're screwed anyway because they aren't parallel anyway. |
| 23:07.32 | Gumboot | So that they don't behave like generic multi-threaded apps and chatter all over each other's cache lines. |
| 23:07.45 | lkcl | frafra: we're held up on finding suitable connectors. |
| 23:08.05 | lkcl | the only people who can actually find what we need - and get proper pricing quotes on - are in china. |
| 23:08.16 | Gumboot | Nothing specific. I just saw it as a problem while reading some gamedev slides and thought things might be improved somehow. |
| 23:08.16 | lkcl | we now have 3 separate people independently looking. |
| 23:08.30 | lkcl | once the connectors are located, the boards can be done in about 7-10 days. |
| 23:08.39 | frafra | oh, cool |
| 23:09.06 | gordan | If your use-case for SSI is new apps, you are aiming a rocket launcher directly at your balls because you are throwing away a pile of control and performance by not designing the concept of distributred computation in at the application level. |
| 23:09.22 | frafra | so the specs about a10 cards are definitive for alpha boards? |
| 23:09.41 | lkcl | the only difference between alpha and beta will be that alpha you get *zero* source code preinstalled; beta you'll get "whatever we as a community managed to get working and proved that most stuff works" preinstalled |
| 23:10.14 | lkcl | and the stable boards will be exactly the same but will be "we managed to prove that everything works, and for a long period of time nobody encountered any problems" |
| 23:11.05 | frafra | they will have the same identical hardware right? |
| 23:11.07 | lkcl | there will if i can persuade the factory to do it be a pre-alpha run of maybe 3 or 4 boards. the problem is that the factory's machines are 1 sqm of PCB all at once, which costs $500 a go. |
| 23:11.10 | lkcl | yes. |
| 23:11.20 | Gumboot | gordan: I have no model in mind. |
| 23:11.26 | frafra | thanks |
| 23:11.29 | Gumboot | Although I'm just starting to wonder where the multi-threaded model came from. |
| 23:11.30 | lkcl | that's why there called alpha, beta and stable. no point changing things because if you changed anything, you're back to square one. |
| 23:11.53 | Gumboot | Did it simply come from un-protected operating systems? |
| 23:11.54 | gordan | Gumboot: Threading is great for low latency interconnects, e.g. multiple cores on the same die. |
| 23:12.17 | gordan | Even on things like Core2 which has 2x2 cores, you find that the throughput decays very rapidly as you have threads spanning cores. |
| 23:12.39 | Gumboot | "spanning cores"? |
| 23:12.49 | gordan | Bad expression. |
| 23:12.58 | gordan | I meant threads migrating and communicating across cores. |
| 23:13.03 | Gumboot | Spanning real cores, rather than ..uhh.. hyperthreads or whatever? |
| 23:13.06 | gordan | Rather than being pinned. |
| 23:13.31 | Gumboot | Talking to themselves as they jump from core to core, or having threads talking to each other from one core to the other? |
| 23:13.47 | gordan | For example, if you are folding and you have the SMP client crunching away on a quad Core2, you'll get about 25% more overall throughput by running 4 instances, each pinned to a different CPU core. |
| 23:14.16 | Gumboot | That's a bit serious. |
| 23:14.21 | gordan | By avoiding the migration between two core dies, you are upping your cache hit rate and removing the thread migration latency between cores. It makes a massive difference. |
| 23:14.22 | Gumboot | Good. |
| 23:15.11 | gordan | The problem is that if you need ONE calculation to complete quickly, and you don't have another n-1 to do at the same time where n is the number of cores, you have no choice. |
| 23:15.27 | gordan | Dual core core2 is OK, because both cores are on the same die with the same L2 cache. |
| 23:16.13 | gordan | Later chips have all cores on the same die which helps a lot, but when you have multi-socket Xeons, you have the same problem with a vengeance because the migration between sockets is even worse. |
| 23:16.47 | gordan | It's one of the contributing reasons why virtualization typically costs you about 40% in performance. |
| 23:17.57 | frafra | what about nand memory? in the wiki page I read "at least 1gb of NAND Flash (possibly up to 16gb)" |
| 23:18.02 | gordan | You are de-coupling the OS's scheduler from the actual hardware by inserting the hyupervisor inbetween. |
| 23:18.35 | gordan | So your OS kernel can't make any kind of a sane, worthwhile decision on whether it is counterproductive or not to try migrating a process to a different core. |
| 23:19.02 | gordan | And your hypervisor just meddles further and schedules things on sub-optimal cores just because they are the most idle. |
| 23:19.25 | gordan | Between all the cache misses and migration latencies, you're looking at typically a 40% performance drop over bare metal. |
| 23:20.23 | gordan | People laugh at me when I make such controversial statements - then I run some tests for them to demonstrate it, and the "vmware specialists" turn various shades of red and purple when challenged to optimize the system to get closer to bare metal performance. |
| 23:21.38 | Gumboot | It doesn't sound at all controversial, but I assert that even without a hypervisor, Linux's page mapping granularity is stealing your cycles. |
| 23:21.44 | gordan | Usually some handwaving and back-peddling about how "that's not what virtualization is about" ensues at some point when they fail to get anywhere with their optimization attempts, unless they sacrifice most of the hypervisor features to close the gap to a "mere" 20%. |
| 23:22.15 | Gumboot | Bad scheduling sounds like it just needs some more coordination between hypervisor and kernel, though. |
| 23:22.28 | Gumboot | Or some more heuristics in the hypervisor. |
| 23:22.35 | Gumboot | Or just some better ones. |
| 23:22.47 | gordan | Heh - and then you throw into the mix the NUMA setups of most modern servers where you have different memory banks hanging off different CPUs, so you have nearer (faster) and further (slower) memory, and you start migrating process to the CPU with memory, etc, and it all gets even worse. |
| 23:23.15 | gordan | It's actually a really hard problem. |
| 23:23.35 | gordan | Xen paravirtualization goes some way toward addressing it, but in my tests it wasn't actually that much better. |
| 23:33.30 | frafra | how much power it will use? |
| 23:39.08 | penguin42 | gah, disappear for an hour or two and has more conversation than the rest of the day on the channel |
| 23:40.34 | penguin42 | hmm hadn't heard of Kerrighed - one of those easy to spell project names |
| 23:41.58 | penguin42 | wonders if it looks similar to scalemp |
| 23:50.11 | Gumboot | adds scalemp to his list |