Hello,
I have a lava setup and right now running two single instance servers. These are pretty high end servers are handling 4-5 Android devices over USB
I need to expand that to multi node setup with maximum DUTs connected to one dispatcher.
The target is only to have android DUTs so that implies a very stable USB hub and stack on the dispatcher machines.
I used a couple of off the shelf desktops in the past and the USB stack could not handle more than 1 device at a time. Any suggestions for hardware that is proven to be solid for dispatchers.
Thanks Sandeep
On 24 June 2016 at 17:40, Sandeep Chawla sandeep@cyngn.com wrote:
Hello,
I have a lava setup and right now running two single instance servers. These are pretty high end servers are handling 4-5 Android devices over USB
Are these devices connected directly to the server or are you using powered USB hubs? (Servers themselves don't always have more than 1 or 2 USB ports.)
I need to expand that to multi node setup with maximum DUTs connected to one dispatcher.
Caution: there are problems there, completely unrelated to LAVA, where the USB stack and fastboot end up causing jobs to sit there and wait for each other when there are multiple USB / adb devices on one dispatcher. We've moved to using LXC in LAVA V2 to solve these problems.
The target is only to have android DUTs so that implies a very stable USB hub and stack on the dispatcher machines.
I used a couple of off the shelf desktops in the past and the USB stack could not handle more than 1 device at a time.
That is a common experience - the Cambridge lab also limits the number of USB devices per dispatcher. Again, we're using LXC to isolate the USB devices and fastboot/adb from each other. The Cambridge lab is also working with a small company with some specialised USB devices (not cheap).
Any suggestions for hardware that is proven to be solid for dispatchers.
Mass market USB stacks can be a real pain - no matter what gets recommended, what it says on the label or packaging is no guarantee of the same chips inside.
Adding Dave to CC as he has more direct experience of the lab setup, including the Cambrionix units.
(Also, I'm about to head off to DebConf16 when I'll not be as easily contactable as usual.)
Thanks Neil for the quick reply.
I have one server (which is more of a powerful desktop - https://system76.com/desktops/ratel) . It can handle 4 devices most of the time. Occasionally we get into the USB fastboot issue. With a general powered USB hub i have been able to take it up to 6 devices. The flock method in dispatcher of restricting fastboot is pretty good, but not foolproof.
I got one cambrionix USB hub, but that is expensive.
I didn't quite understand how LXC will help with fastboot.
My understanding of LXC was that it replaces KVM for a multinode setup as it is more lightweight and supports usb for things like adb over USB.
Thanks Sandeep
On Fri, Jun 24, 2016 at 10:47 AM, Neil Williams neil.williams@linaro.org wrote:
On 24 June 2016 at 17:40, Sandeep Chawla sandeep@cyngn.com wrote:
Hello,
I have a lava setup and right now running two single instance servers.
These
are pretty high end servers are handling 4-5 Android devices over USB
Are these devices connected directly to the server or are you using powered USB hubs? (Servers themselves don't always have more than 1 or 2 USB ports.)
I need to expand that to multi node setup with maximum DUTs connected to
one
dispatcher.
Caution: there are problems there, completely unrelated to LAVA, where the USB stack and fastboot end up causing jobs to sit there and wait for each other when there are multiple USB / adb devices on one dispatcher. We've moved to using LXC in LAVA V2 to solve these problems.
The target is only to have android DUTs so that implies a very stable USB hub and stack on the dispatcher machines.
I used a couple of off the shelf desktops in the past and the USB stack could not handle more than 1 device at a time.
That is a common experience - the Cambridge lab also limits the number of USB devices per dispatcher. Again, we're using LXC to isolate the USB devices and fastboot/adb from each other. The Cambridge lab is also working with a small company with some specialised USB devices (not cheap).
Any suggestions for hardware that is proven to be solid for dispatchers.
Mass market USB stacks can be a real pain - no matter what gets recommended, what it says on the label or packaging is no guarantee of the same chips inside.
Adding Dave to CC as he has more direct experience of the lab setup, including the Cambrionix units.
(Also, I'm about to head off to DebConf16 when I'll not be as easily contactable as usual.)
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
On Friday 24 June 2016 11:31 PM, Sandeep Chawla wrote:
I didn't quite understand how LXC will help with fastboot.
In V2 when a fastboot device is requested a transparent LXC device could be created automatically. Think of this transparent LXC device like an intermediate dispatcher, where all the commands that used to run from the dispatcher directly, now runs via LXC (ie., contained). This gives the flexibility of choosing your own operating system (currently only Debian and Ubuntu are supported) and java versions to communicate with the DUT. adb daemon is started within the LXC container in order to communicate with the device, similarly the deployment happens via fastboot commands within the container. Once the job finishes the transparent LXC container gets destroyed.
See https://git.linaro.org/lava-team/refactoring.git/blob/HEAD:/nexus9-simple.ya... for a sample job definition in V2 that exercises the above.
A sample job run with nexus9 that demonstrates the above is here - https://staging.validation.linaro.org/scheduler/job/151871
My understanding of LXC was that it replaces KVM for a multinode setup as it is more lightweight and supports usb for things like adb over USB.
We are moving towards dropping multinode for running tests on fastboot devices. The above job is one such example. Also, shortly we will add support for devices such as Hikey, DragonBoard and whatever that uses fastboot and adb.
Thank You.
Thanks Senthil for the LXC explanation.
So each dispatcher machine will be running multiple LXC instances. One for each USB device connected.
In that case , it would need to be pretty solid machine - say i7 atleast, 8GB RAM and 200 GB Hard disk space. I am considering something similar to http://www.newegg.com/Product/Product.aspx?Item=9SIA19P3RN6460 which to shelf space. What does the LAVA lab production instance (http//:validation.linaro.org) for dispatcher machines for USB/Android devices
Thanks Sandeep
On Fri, Jun 24, 2016 at 11:13 AM, Senthil Kumaran S < senthil.kumaran@linaro.org> wrote:
On Friday 24 June 2016 11:31 PM, Sandeep Chawla wrote:
I didn't quite understand how LXC will help with fastboot.
In V2 when a fastboot device is requested a transparent LXC device could be created automatically. Think of this transparent LXC device like an intermediate dispatcher, where all the commands that used to run from the dispatcher directly, now runs via LXC (ie., contained). This gives the flexibility of choosing your own operating system (currently only Debian and Ubuntu are supported) and java versions to communicate with the DUT. adb daemon is started within the LXC container in order to communicate with the device, similarly the deployment happens via fastboot commands within the container. Once the job finishes the transparent LXC container gets destroyed.
See
https://git.linaro.org/lava-team/refactoring.git/blob/HEAD:/nexus9-simple.ya... for a sample job definition in V2 that exercises the above.
A sample job run with nexus9 that demonstrates the above is here - https://staging.validation.linaro.org/scheduler/job/151871
My understanding of LXC was that it replaces KVM for a multinode setup as it is more lightweight and supports usb for things like adb over USB.
We are moving towards dropping multinode for running tests on fastboot devices. The above job is one such example. Also, shortly we will add support for devices such as Hikey, DragonBoard and whatever that uses fastboot and adb.
Thank You.
Senthil Kumaran S http://www.stylesen.org/ http://www.sasenthilkumaran.com/
-
Neil Williams -
Sandeep Chawla -
Senthil Kumaran S