Jump to content

THE testing thread


lanefu

Recommended Posts

29 minutes ago, Tido said:

Why did you choose  the one with a hinge   and not:

Hirose DM3CS (Hinge, Push-Pull, manual, without ejection mechanism)

Hirose DM3AT and DM3BT (Push - Push, with ejection mechanism)

Hirose DM3D (Push -Pull, manual, without ejection mechanism)

Can not recall now. I remember thinking about footprint. But also it may be this one was available at TME those days. From the other hand the cards are inserted once so way of installation is not so important. At least to me. 

Link to comment
Share on other sites

1 hour ago, Igor said:

FYI. I am talking with Olimex

better to know late than never ;)

 

1 hour ago, Hijax said:

the cards are inserted once

under this circumstance it doesn't matter, unless you have to open it now and then for some unforeseen reason. That said, I would go for "Push - Push, with ejection mechanism" to be on the save side. The SDcard-Mux is inbetween and the Serial-Multiplexer on top - if I understand that correct. So, a replacement of the SDcard would force you to take it apart.

 

Link to comment
Share on other sites

Small update.

 

We are able to create one cycle of a full sbc-bench, io and network testing in around 1h on all devices at once. Tests are still distant from perfection, but slowly we are getting some overview which will tell where to look closely https://dl.armbian.com/_test-reports/2020-04-14_09.06.24.html

 

 

 

 

Link to comment
Share on other sites

On 4/12/2020 at 6:59 PM, Igor said:

I am talking with Olimex to produce this board

 

Did you see this information (on page 4), the Google Doc represents the latest findings:

Quote

I think the 2 last parts, 74LS151 and 74LS157, should be HC not LS, since HC is 3.3V compatible but not LS which are 5V only ...

 

Link to comment
Share on other sites

47 minutes ago, Igor said:

if you have time

well, depends on the person, but as I use to say: It is not whether you have time, it is whether you take the time ;)

 

SBCBENCHPASS=${PASSES}	# sbc-bench will run on each cycle by default, set to 1 to run only on first

{PASSES } will be read from the first line of the configuration file, but I don't know this SW SBCbenchPass, what is it?

 

UPLOAD_SERVER=""			# server for report upload
UPLOAD_LOCATION=""			# location on that server

To do that and to filter my results, wouldn't each person need a unique, but requrring identity?

 

Looks like it has some troubles with:

iperf-on-all-interfaces.include: Line 20: iperf3:

It started:

[ o.k. ] 0. Trying [ 19:01:15 - 11.5 ]
[ o.k. ] 0. RockPi-4B Linux 4.4.213-rockchip64 stable [ 19:02:02 - 11.5 Uptime:  2:17 ]

still not finished with 2 Passes at 20:31

 

 

Although I repeat myself of 31. March:

there is no information given, that my system is downloading software. I hate these kind of installer like Firefox, TEAMS and    armbian autotests.

Do you mind to add a line like: It needs the following software;....,  if not already installed it will install it now:  (list the software)

 

Link to comment
Share on other sites

54 minutes ago, Tido said:

To do that and to filter my results, wouldn't each person need a unique, but requrring identity?

 

I don't count more then a few people doint this. But not at this stage - utility is very bugy as you can see. We don't do nothing with the data yet - only collect and upload.

 

54 minutes ago, Tido said:

{PASSES } will be read from the first line of the configuration file, but I don't know this SW SBCbenchPass, what is it?


I took @tkaiser sbc-bench as a core tool for making a load + generate numbers. There its defined how many times this test is run. You can run test per board many times but you don't run sbc-test each time. In my real tests I do 3 passes of tests but I only run sbc-test in first run. But sometimes I want to compare number and ... Don't bother with this. Tests scenarios is not something you need to document nor understand.

 

54 minutes ago, Tido said:

there is no information given, that my system is downloading software.

 

I will start to care about that perhaps next year, if I will be the only user, never. My main concern is that app becomes usable, that additional hardware can be implemented, ... not what users might think about. Look on this as an internal tool.

Link to comment
Share on other sites

@Igor, after fiddling around with: systemd-analyze time  -  this would be a valuable information on the testing, wouldn't it?

:~$ systemd-analyze time
Startup finished in 54.100s (kernel) + 1min 30.978s (userspace) = 2min 25.078s 
graphical.target reached after 1min 30.924s in userspace

fun fact, is the server build but it says: graphical.target reached after 1min 30.924s in userspace

 

Link to comment
Share on other sites

1 hour ago, Tido said:

this would be a valuable information on the testing, wouldn't it?


Absolutely.

 

You can try to add a test for that, after 7z.

Link to comment
Share on other sites

4 hours ago, Igor said:

after 7z

0119-7-zip-benchmark.bash -  I would have put that before starting any test, so I had a first value in case anything goes south.

Another idea is to collect the values (strip out the numbers).. I left mine in english what if it is in another language, can regex extract that..  just looked at the man-page even better if there is a command that only returns the values - cannot see one right away.

Collect the values of several passes in a global array and report only the best and the worst.

 

Link to comment
Share on other sites


One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...

Link to comment
Share on other sites

23 hours ago, Igor said:

 


One test board from this topic will be installed at this location and another at my desk and elsewhere. We will try to join them.

After test boards come, some more coding has to be done. Also to have better overview over the test process. Currenlty test results looks like this: https://dl.armbian.com/_test-reports/2020-05-03_15.57.22.html Its still more or less a data collection without any proper analysis ...

 

 

 

that's super awesome @Igor!

Link to comment
Share on other sites

1 hour ago, Hijax said:

stacking of them on top of SBC

to stack the green PCB on top of the blue PCB according to the pictures from @Igor , right?

Well, if only a THT part is wrong, easy. This is not ideal, but much easier than a wrong SMT item.

Link to comment
Share on other sites

1 hour ago, Hijax said:

Nice. But one 2x5 connector shall have long legs. To allow interconnection between boards/ stacking of them on top of SBC


Yes. I also notice this and I hope that is the only problem ;) Will report later when I do the proper unboxing. I'll ship it ASAP. 

 

5 minutes ago, Tido said:

right?

 

Right.

Link to comment
Share on other sites

Order of stacking: to make 7seg LED visible, I.e.

SBC -> Blue -> Green

 

When stacked, SBC shall be powered from this sandwich top board connector. SBC thus shall be able to switch ports, what shall be reflected on 7seg. 

 

7seg represents the port, serial lines (RX/TX) shall be routed to.

 

In princible  via I2C we program 16bit word.  Low byte is a power dsictribution, any of those bits control mosfets to power the connetced SUT SBC.

High byte is split into two 4bit chunks. Low control serial port mux, high are used by blue board to connect SD card.

 

Idea is, to be able to power all but one SUT-SBC, write data to SD card, release SD by SBC, power on specific  SUT-SBC using the SD we just modifying, wait for RS232 communication to confirm booting went OK.  In the meantine one can switch serial mux to other port to write something as terminal command.

 

 

Link to comment
Share on other sites

OK, now that I have these in-hand.  The SD multiplexer board, for the 2x5 pin header, should that be a pass-through connector?  Mine are soldered with a socket facing downward on both boards.  Easy fix for me, maybe not for some of the others.  ;-)  All connectors are Mini-SPOX other than the SD card mini-board. the 1x4 pin header on each is populated, on the SD board it faces "up", on the serial board "down" I would assume one should be a socket.

 

[edit] Well, I was not on the recent page when I wrote this, haha.

Link to comment
Share on other sites

On 3/24/2020 at 7:27 PM, Igor said:

When people will realise, when we will know how to tell them that, that stability of their systems depends from the things like this, then perhaps someone will also follow and wire stuff together, perhaps find it interesting to deal with and do it instead of me ... :)

 

This is essentially a (cool) tool for us to quickly see how things looks from the users perspective. Now and for the future. With most boards at once. If anyone wants to have this look or help to creates that looks, one shell join. But I don't expect people staying in the line to help out. Even its is in their, ours interest.

How does one acquire these marvelous boards? 

Link to comment
Share on other sites

Serial and power mux board is ready for ordering. However before I do so, I need to wait till SD card mux board redesign is complete at least overall idea is “approved”.

 

As previously written the major change is to switch from simple SDI interface towards SDIO one allowing full speed communication with card. This requires 8 pins thus not only mux board but also card adapter tuning. 

Recently idea under consideration is to move SD mux board away from stacking and make it more alike USB Mass Storage device. 

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines