Raspberry Pi Catch-All

muraii wrote:

Edwin, I thought about that, but it'd have to sit at work as my home internet is the culprit for Verizon's traffic shaping. Definitely worth looking into.

Cronox, that definitely is a better choice than my erstwhile gaming machine, in terms of power consumption and noise. I know trueheart78 also runs a webserver (or did) on his, so I wonder: how much concurrent activity can it handle?

Guess it's time to find out.

I still run a webserver - talk about a fantastic "set it and forget it" device

Runs MongoDB, nginx, nodejs, and PHP stuff just fine. Just note that you will need to compile some of this from source (Mongo took over a day).

Radical Ans wrote:

I just ordered myself one of these bad boys. I have a MIDI controller that only has a USB port and not the traditional 5 pin DIN connectors. This presents a problem in that I can't use it to control older sound modules and synths that only accept the old style MIDI inputs. The plan is to take a USB to MIDI cable that has DIN connectors and connect it to the Pi. I'll then connect the controller via USB and use the PI to read its MIDI messages and pass them out to the DIN connectors. Hopefully I can do this without introducing too much latency. We'll see.

Not to talk you out of a project, but I've done something similar with Bome's MIDI Translator. I didn't really stress test it but I didn't notice any perceivable added latency.

LiquidMantis wrote:
Radical Ans wrote:

I just ordered myself one of these bad boys. I have a MIDI controller that only has a USB port and not the traditional 5 pin DIN connectors. This presents a problem in that I can't use it to control older sound modules and synths that only accept the old style MIDI inputs. The plan is to take a USB to MIDI cable that has DIN connectors and connect it to the Pi. I'll then connect the controller via USB and use the PI to read its MIDI messages and pass them out to the DIN connectors. Hopefully I can do this without introducing too much latency. We'll see.

Not to talk you out of a project, but I've done something similar with Bome's MIDI Translator. I didn't really stress test it but I didn't notice any perceivable added latency.

Thanks for the tip. I'll probably still give it a go on the Pi since I don't have a laptop and I'm looking for something portable.

trueheart78 wrote:
muraii wrote:

Edwin, I thought about that, but it'd have to sit at work as my home internet is the culprit for Verizon's traffic shaping. Definitely worth looking into.

Cronox, that definitely is a better choice than my erstwhile gaming machine, in terms of power consumption and noise. I know trueheart78 also runs a webserver (or did) on his, so I wonder: how much concurrent activity can it handle?

Guess it's time to find out.

I still run a webserver - talk about a fantastic "set it and forget it" device

Runs MongoDB, nginx, nodejs, and PHP stuff just fine. Just note that you will need to compile some of this from source (Mongo took over a day).

I kind of want to setup a Ghost server on my Pi and eventually a Mailpile.

trueheart78 wrote:
muraii wrote:

Edwin, I thought about that, but it'd have to sit at work as my home internet is the culprit for Verizon's traffic shaping. Definitely worth looking into.

Cronox, that definitely is a better choice than my erstwhile gaming machine, in terms of power consumption and noise. I know trueheart78 also runs a webserver (or did) on his, so I wonder: how much concurrent activity can it handle?

Guess it's time to find out.

I still run a webserver - talk about a fantastic "set it and forget it" device

Runs MongoDB, nginx, nodejs, and PHP stuff just fine. Just note that you will need to compile some of this from source (Mongo took over a day).

Would be great if you had a comparable-architecture device with more oomph to compile on, then push out to the Pi. I recall upstream someone recommended against compiling on the Pi itself, but unless there's a way to virtualilze the compiler's target architecture for compilation, the only way is to have an ARM system to do so, yeah?

Edwin wrote:
trueheart78 wrote:
muraii wrote:

Edwin, I thought about that, but it'd have to sit at work as my home internet is the culprit for Verizon's traffic shaping. Definitely worth looking into.

Cronox, that definitely is a better choice than my erstwhile gaming machine, in terms of power consumption and noise. I know trueheart78 also runs a webserver (or did) on his, so I wonder: how much concurrent activity can it handle?

Guess it's time to find out.

I still run a webserver - talk about a fantastic "set it and forget it" device

Runs MongoDB, nginx, nodejs, and PHP stuff just fine. Just note that you will need to compile some of this from source (Mongo took over a day).

I kind of want to setup a Ghost server on my Pi and eventually a Mailpile.

Holy Bojangles, Batman! Ghost and Mailpile look sweet. Ghost looks straightforward enough, but I would have to get up-to-speed on managing MX records and stuff to host my own mail server. I already have mutt set up but tend to do all mail on my iPhone (in Mailbox, which is fab). Between this and IRC/znc, I may need to find some server space on the cheap somewhere.

I am the opposite where I have no idea what the first thing to do with Ghost but I could setup Mailpile but I want to wait till its closer to being done.

muraii wrote:
trueheart78 wrote:
muraii wrote:

Edwin, I thought about that, but it'd have to sit at work as my home internet is the culprit for Verizon's traffic shaping. Definitely worth looking into.

Cronox, that definitely is a better choice than my erstwhile gaming machine, in terms of power consumption and noise. I know trueheart78 also runs a webserver (or did) on his, so I wonder: how much concurrent activity can it handle?

Guess it's time to find out.

I still run a webserver - talk about a fantastic "set it and forget it" device

Runs MongoDB, nginx, nodejs, and PHP stuff just fine. Just note that you will need to compile some of this from source (Mongo took over a day).

Would be great if you had a comparable-architecture device with more oomph to compile on, then push out to the Pi. I recall upstream someone recommended against compiling on the Pi itself, but unless there's a way to virtualilze the compiler's target architecture for compilation, the only way is to have an ARM system to do so, yeah?

I'm fairly certain you can cross compile for ARM devices using GCC. That way you do all your coding and building on a Linux box and then send it on over to the target board. I don't know the specifics for setting it up with the Pi but it doesn't sound impossible.

Wife got me a 3rd Pi for our anniversary - debating what to do with it now

trueheart78 wrote:

Wife got me a 3rd Pi for our anniversary - debating what to do with it now :)

Happy anniversary!

I just heard that Pi has access to a true hardware random number generator, which is pretty cool. Dunno how good it is, but those can cost a LOT of money, so having it on a $35 board is pretty cool.

I got my quad core udoo yesterday still haven't figured out what I'm going to do with it.

I currently use a Verizon Mifi LTE thingy for internet. The service is okay, but the device seems underpowered for both serving as a wifi router and pulling signal from the towers. I'd like to connect it to my wifi router, but I believe I'd need to be running something like dd-wrt which my D-Link 655 doesn't support.

I'm thinking of taking advantage of the usbnet Linux module to pair my Pi to the Mifi, then somehow connect my D-Link as an access point to the network via the Pi.

It's late and this sounds dumb but does it sound like the beginning of something workable?

Does the MiFi have an Ethernet port? If so, you could just plug the router in directly.

Otherwise, if you're talking about pairing the Pi with the MiFi, and then using it to share that access over Ethernet, that should work. The simplest method would probably be to do NAT and firewalling on the Pi: it would become your external router, instead of your D-Link. Then you connect the D-Link to the Pi on an internal port, instead of the external WAN port, and it should then just bridge the wireless to the Pi for you.

Alternately, you try to keep using the D-Link as a firewall, and set up the Pi as a bridge, one forwarding between wireless and Ethernet. Instead of doing NAT and firewalling on the Pi, you're just trying to make it stupidly shovel packets back and forth between the two interfaces. In this variant, you could connect the D-Link's external interface to the Pi.

The last time I tried to do this with a Linux machine, years ago, it was a freaking minefield. Bridging between Ethernet and wireless just wouldn't work, at the time. NAT and firewalling, while ostensibly more complex, was tremendously easier. All that infrastructure is built, battle-tested, and ready to go.... the Linux kernel knows all about reading incoming packets, massaging the heck out of them, and sending them out another interface. But when I was last doing this, the 'bridge' code, which is supposed to just copy everything it sees verbatim between two interfaces, did not like wireless devices, and wouldn't work with them.

The dumb and simple system, in other words, was complex, and the complex system was easy.

If the Mifi had Ethernet I'd just connect them over Ethernet. [That's not snark. ]

I'm going to do USB to the Pi and then hook it to an internal port note D-Link and then figure out what else needs done.

If the D-Link firmware supports it, you could also do 'client bridging', where the D-Link becomes the wireless client of the MiFi, and then provides Internet on its LAN ports. But it won't repeat the signal, you have to either plug in via wires, or else get another router to plug in via wired and then create a new network.

And, of course, if you're buying a new AP anyway, you could just buy one that does client bridging (anything that supports DD-WRT should work) and then plug the D-Link into that.

That might be easier than trying to get the USB NAT working on the Pi, but would cost more. And the reliability might be better. I've had pretty spotty results with USB wireless dongles, where DD-WRT-based client bridging was rock solid on my WRT-54G. Ran it for many months at a time between reboots, and those were for maintenance, not because of any kind of failure.

Malor wrote:

If the D-Link firmware supports it, you could also do 'client bridging', where the D-Link becomes the wireless client of the MiFi, and then provides Internet on its LAN ports. But it won't repeat the signal, you have to either plug in via wires, or else get another router to plug in via wired and then create a new network.

And, of course, if you're buying a new AP anyway, you could just buy one that does client bridging (anything that supports DD-WRT should work) and then plug the D-Link into that.

That might be easier than trying to get the USB NAT working on the Pi, but would cost more. And the reliability might be better. I've had pretty spotty results with USB wireless dongles, where DD-WRT-based client bridging was rock solid on my WRT-54G. Ran it for many months at a time between reboots, and those were for maintenance, not because of any kind of failure.

Yeah, unfortunately while I like the D-Link it's not supported by DD-WRT. It may support client bridging. I just haven't tried anything yet. That would require tracking down a {mini, micro}-USB-to-RJ45. Curiously enough, I have a standard USB-to-RJ45 in my backpack. Found it at work and wanted to bring it home to do research. Have yet to do so.

When I get back from Minecon I'ma probably just connect to my Linux desktop and work with usbnet. If it's stable enough, I'll probably leave it be for a while. Using the Pi to bridge was more curiosity as to how feasible it is as wanting to use that as a permanent solution, I realize. If I'm going to toy with it, I don't want it sitting as a critical component of my household networking.

Now to figure out what to actually do with my Pi. Maybe I'll bug some Christmas gifts.

Client bridging works over the wireless. An AP in client bridge mode is no longer an AP. It looks like a laptop or something instead, a standard client. And then it shares its connection over its Ethernet ports.

I'm not sure what the USB-to-RJ45 cables are that you're talking about. Those two technologies don't normally mix directly, they require an adapter, driven by a CPU of some sort. If you're planning to plug the MiFi's USB port into an RJ45 port on the D-Link, I don't think anything is going to happen.

Malor wrote:

Client bridging works over the wireless. An AP in client bridge mode is no longer an AP. It looks like a laptop or something instead, a standard client. And then it shares its connection over its Ethernet ports.

I'm not sure what the USB-to-RJ45 cables are that you're talking about. Those two technologies don't normally mix directly, they require an adapter, driven by a CPU of some sort. If you're planning to plug the MiFi's USB port into an RJ45 port on the D-Link, I don't think anything is going to happen.

Neither do I.

Neither do I.

Then I don't understand this sentence:

It may support client bridging. I just haven't tried anything yet. That would require tracking down a {mini, micro}-USB-to-RJ45.

Why would client bridging require tracking down a USB cable? And what would a USB-to-RJ45 even do?

Malor wrote:
Neither do I.

Then I don't understand this sentence:

It may support client bridging. I just haven't tried anything yet. That would require tracking down a {mini, micro}-USB-to-RJ45.

Why would client bridging require tracking down a USB cable? And what would a USB-to-RJ45 even do?

I don't know what it does, but I have one in my backpack. I wrote that sentence before you explained that bridging is a wireless modality, not wired. I assumed it needed to be wired in the same way that I typically daisy chain my routers. If I were attaching the Mifi to the router directly, it would require a USB-to-RJ45 cable with a micro- or mini-USB connector. The Mifi does not have an Ethernet port, but does support Ethernet out its mini- or micro-USB port. Given I have a breed of this cable (at least in terms of connectors), albeit with a different kind of USB connector, I presumed it was possible.

I don't know what it does, but I have one in my backpack

That's really weird. I can't imagine what you'd use such a thing for, unless it has a built-in Ethernet adapter. Maybe it's for USB range extension? Maybe?

The Mifi does not have an Ethernet port, but does support Ethernet out its mini- or micro-USB port. Given I have a breed of this cable (at least in terms of connectors), albeit with a different kind of USB connector, I presumed it was possible.

Ah, okay, I think what's going on there is that the MiFi looks like a USB-attached Ethernet device. So, you plug it into a PC, and the PC thinks it's a NIC on a stick, so to speak. I don't think any router out there will let you plug in new devices on USB, at least unless you're running a Linux derivative with the ability to configure things at the command line.

Boy, I just don't know what that cable is for. Very interested to find out.

So, I went ahead and picked one up, because access to a hardware RNG on the cheap is pretty appealing.

There's instructions here on how to get to it; you basically install a kernel module that provides a new character device, /dev/hwrng, and then you install the "rng-tools" package, which reads from that, and dumps entropy into the main kernel pool. So you still get whatever entropy the kernel itself is generating, and then this device more or less becomes a backstop. Anytime the kernel gets low, rng-tools fills it back up again. And then, even if there's no demand for entropy, rng-tools occasionally stirs a little more data in, just in case.

The hwrng device seems to generate between 50 and 100Kbytes of data per second, which is not bad for such a cheap thing, and should be able to keep up with anything I can imagine running on the Pi.

You can usually expect to spend hundreds of dollars on these things, so having it as an extra on such cheap hardware is really a very nice surprise.

edit: oh, and I bought mine via Amazon from a seller called "Canakit". They seem to sell a bunch of other Pi-related stuff, and the case they made for it is really good. I bought a Nexus 7 charger from ASUS to power it, and a cheapo Transcend 16-gig SD card.

I took a bunch of time to resize the official Raspbian image to fit the SD card, and then after I booted it up, discovered that it's a built-in function... Raspbian has a little pop up configuration menu that will resize itself to use the whole card. Very clever.

I find it kind of amusing to have the whole thing set up for Great Britain by default. You can tell they're proud it's coming from there.

Oh, and if you use Raspbian, don't forget to donate a few bucks. The people who made it bought a bunch of hardware and put in a ton of time to make it happen.

Heh, so I'm running the output from the pi through Dieharder, which is a test suite to try to detect patterns in random number generation. This is an extremely hard problem, because real random numbers will sometimes look like they have patterns; algorithms to do pattern matching are, by necessity, flawed and imperfect, and apparently will usually fail if you give them enough input. (given enough randomness, I gather that any pattern matcher will eventually find patterns.) So Dieharder is flawed, but it'll still be interesting to see what it thinks about the Pi's HWRNG.

Problem is, it's going to take a long, long time. It uses a >lot< of random bits. Catting /dev/urandom into it shows 3.01e6 bytes per second, and it takes at least an hour to run. (I haven't finished the first run there, yet.) The pi's HWRNG is generating 2.6e4, or a little more than two orders of magnitude slower, so I'm looking probably 100 to 200 hours, maybe more, and that's just one run.

Will report back, but it'll be awhile.

So, um, the /dev/urandom test took about 5 hours to run (and failed a couple of tests), which implies that testing the Pi is going to be close to 500 hours. Somewhat foolishly, I'm piping the /dev/hwrng to another machine to do the analysis (I thought it would make things run faster: I started this before I realized that the bottleneck was the random numbers, not the CPU), so hopefully I can keep the two machines up for a month. If not, hopefully I'll be able to restart the tests partway through; it looks like dieharder has the ability to tell it what tests you want run.

Catting /dev/hwrng just beats the heck out of the Pi. I guess it's busy-waiting on the RNG, and it's showing full processor load, all the time. This may end up being something of a stress test, too.

The results so far look fine. It looks pretty random to me: some tests look really close to center, and a couple are fairly unlikely, but there haven't been any actual "failures" yet. If there are problems with the RNG on the Pi, the first 20 or so dieharder tests haven't seen them.

The Pi is probably one of the slowest processors you can find. As well it should be for $35, but it's still just so slow. I've ran a web server off of it, and it would work fine for completely static sites, but as soon as you put up anything dynamic, that means work for the processor, which means that it's going to be seconds before anything loads. Just how it goes.

I wouldn't consider the Pi viable for any type of number crunching. I think trueheart78 said it took him an entire weekend to compile something simple on the Pi from source.

Citizen86 wrote:

The Pi is probably one of the slowest processors you can find. As well it should be for $35, but it's still just so slow. I've ran a web server off of it, and it would work fine for completely static sites, but as soon as you put up anything dynamic, that means work for the processor, which means that it's going to be seconds before anything loads. Just how it goes.

I wouldn't consider the Pi viable for any type of number crunching. I think trueheart78 said it took him an entire weekend to compile something simple on the Pi from source.

Which webserver did you try? I'm serving up PHP on nginx alright (no benchmarks).

As for compiling... Yeah. I wanted to get node.js and mongo support, for potential Meteor use. MongoDB took around a day to compile.

Well, I wasn't expecting much from the processor in this specific case, I was just, I thought, copying bytes from the hardware RNG, which is like a hundred K a second. That should barely take any CPU at all, even on a teeny little one like the Pi's. A 286 could do that. But the driver seems to do busy-waiting, so it's putting a lot of load on it, and anything else on the machine is glacial.

I used to use computers all the time that were this slow, so while I do get a little frustrated with the speed of aptitude and dpkg in Raspbian, it really doesn't annoy me that much. If I set my expectations back to 2000, which isn't that hard, since I was there at the time ( ) then it's actually a pretty fast little machine. It was only thirty five bucks, it's hard to be uptight with it.

The CPU on the Pi was never intended to be used this way. It's just a tiny peripheral on a very large chip. Almost everything that we're doing with it is, more or less, by accident. We're using the tiniest side feature as the main reason to buy it.

I really bought it to generate random numbers, and it's more than fast enough to do that, and just so incredibly cheap compared to most options. There were EntropyKeys available for awhile at about $100, but they don't seem to be in production anymore, and the next cheapest thing I know is about $800. So $35 for a hundred K a second of apparently true random numbers is bloody fantastic. Even if it had no CPU at all, and I had to plug it in via USB or something, it would be a hell of a deal.

edit: plus, I can put it in service as a backup DHCP and DNS server, and it'll take just a few watts to run. I'm really very, very pleased with it.

Does it make sense to scale horizontally and just buy a few pi's?

Not for what I'm doing with it. One's fine. The only reason it's CPU-loaded is because I'm testing the RNG on it, and that's because the driver is weird.

If I bought more, and tested each one on a different piece of the test suite, I'm not sure the result would be as meaningful.

And I have no pressing need to test it anyway, so spending a bunch of money for a one-time thing that's merely curiosity would be kind of silly.