[Fuego] Time sync

[Fuego] Time sync

[Muk Anc]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

Hello all,
I am looking for some information about time syncing the fuego tests with DUT logs. Our DUT has a RTC, but loses time info on every reboot. Is there a way I can set the time on the board from Fuego? This will help us generate timestamped logs on DUT and thus sync the board logs to the Fuego logs.

Thanks and regards,
Muktabh

[-- Attachment #2: Type: text/html, Size: 1444 bytes --]

Re: [Fuego] Time sync

[Bird, Tim]

> -----Original Message-----
> From: Fuego <fuego-bounces@lists.linuxfoundation.org> On Behalf Of Muk Anc
> 
> Hello all,
> I am looking for some information about time syncing the fuego tests with DUT logs. Our DUT has a RTC, but loses time info on every
> reboot. Is there a way I can set the time on the board from Fuego? This will help us generate timestamped logs on DUT and thus sync the
> board logs to the Fuego logs.

This is possible inside Fuego.

You can do something like this, from inside any test:

cmd "date $(date +%m%d%H%M%Y.%S)"

This will get the date from the host machine, and then executes date on the DUT
using the resulting string.  If the DUT is using NTP or systemd's timesyncd, then
this might not work.  (But I presume that's not the case if the board doesn't
have the correct time on boot).

You can put this command at the end of the test_deploy() function in a fuego_test.sh script,
or maybe at the beginning of the test_run() function.

This would cause the synchronization to happen for the test you put it in.  This will work
if you have a pre-determined set of tests.  You could add this line to 
the first test your run after rebooting.  Or you could make a test specifically to perform
this operation, and run it before other tests.

If you want to perform the time synchronization for every test, then there are ways to
add this to an overlay function, and trigger it using a special value for DISTRIB in the
board file.

This is a bit complicated, but let me know if you'd like to do this, and I'll write some
instructions.

I hope this helps.
 -- Tim

Re: [Fuego] Time sync

[Bird, Tim]

Muk,

I decided to write a test to implement the feature you described.

It is called Functional.time_sync_from_host, and it is now available 
in the fuego-core repository, if you'd like to use it.  If you do use it,
please let me know if it provides a solution for the issue you
described.

I just pushed it to the fuego-core repository, so you'll need to do
a 'git pull' to get it.

Alternatively, you can also see it online here:
https://bitbucket.org/fuegotest/fuego-core/src/master/tests/Functional.sync_time_from_host/

Regards,
 -- Tim



> -----Original Message-----
> From: Bird, Tim
> 
> > -----Original Message-----
> > From: Fuego <fuego-bounces@lists.linuxfoundation.org> On Behalf Of Muk Anc
> >
> > Hello all,
> > I am looking for some information about time syncing the fuego tests with DUT logs. Our DUT has a RTC, but loses time info on every
> > reboot. Is there a way I can set the time on the board from Fuego? This will help us generate timestamped logs on DUT and thus sync the
> > board logs to the Fuego logs.
> 
> This is possible inside Fuego.
> 
> You can do something like this, from inside any test:
> 
> cmd "date $(date +%m%d%H%M%Y.%S)"
> 
> This will get the date from the host machine, and then executes date on the DUT
> using the resulting string.  If the DUT is using NTP or systemd's timesyncd, then
> this might not work.  (But I presume that's not the case if the board doesn't
> have the correct time on boot).
> 
> You can put this command at the end of the test_deploy() function in a fuego_test.sh script,
> or maybe at the beginning of the test_run() function.
> 
> This would cause the synchronization to happen for the test you put it in.  This will work
> if you have a pre-determined set of tests.  You could add this line to
> the first test your run after rebooting.  Or you could make a test specifically to perform
> this operation, and run it before other tests.
> 
> If you want to perform the time synchronization for every test, then there are ways to
> add this to an overlay function, and trigger it using a special value for DISTRIB in the
> board file.
> 
> This is a bit complicated, but let me know if you'd like to do this, and I'll write some
> instructions.
> 
> I hope this helps.
>  -- Tim

Re: [Fuego] Time sync

[Muk Anc]

[-- Attachment #1: Type: text/plain, Size: 3546 bytes --]

Hello Tim,
Thank you so much for setting this up. I will give this a try and update you in a few days.

I would also like to pose another question while we are at it.
I have an ADC on our DUT. I would like to read this ADC every second while a batch test is running. The batch test runs around 20 individual tests. I would like to start reading this ADC and show its readings on the console (I use the FTC command to trigger the batch test) at the beginning of the first sub test, and stop when the batch test finishes, either successfully or due to a failure of a sub test.

Currently, I have updated a few of the subtest’s test script to additionally read the ADC and echo the output, but I can do this only for tests that run for a long period of time, e.g. memtest. While memtest is running in the background, I keep reading and outputting the ADC every second. What would be the best way to decouple this?

Regards
Muktabh


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Bird, Tim<mailto:Tim.Bird@sony.com>
Sent: Friday, 22 April 2022 23:15
To: Muk Anc<mailto:muk.anc@outlook.com>; fuego@lists.linuxfoundation.org<mailto:fuego@lists.linuxfoundation.org>
Subject: RE: Time sync

Muk,

I decided to write a test to implement the feature you described.

It is called Functional.time_sync_from_host, and it is now available
in the fuego-core repository, if you'd like to use it.  If you do use it,
please let me know if it provides a solution for the issue you
described.

I just pushed it to the fuego-core repository, so you'll need to do
a 'git pull' to get it.

Alternatively, you can also see it online here:
https://bitbucket.org/fuegotest/fuego-core/src/master/tests/Functional.sync_time_from_host/

Regards,
 -- Tim



> -----Original Message-----
> From: Bird, Tim
>
> > -----Original Message-----
> > From: Fuego <fuego-bounces@lists.linuxfoundation.org> On Behalf Of Muk Anc
> >
> > Hello all,
> > I am looking for some information about time syncing the fuego tests with DUT logs. Our DUT has a RTC, but loses time info on every
> > reboot. Is there a way I can set the time on the board from Fuego? This will help us generate timestamped logs on DUT and thus sync the
> > board logs to the Fuego logs.
>
> This is possible inside Fuego.
>
> You can do something like this, from inside any test:
>
> cmd "date $(date +%m%d%H%M%Y.%S)"
>
> This will get the date from the host machine, and then executes date on the DUT
> using the resulting string.  If the DUT is using NTP or systemd's timesyncd, then
> this might not work.  (But I presume that's not the case if the board doesn't
> have the correct time on boot).
>
> You can put this command at the end of the test_deploy() function in a fuego_test.sh script,
> or maybe at the beginning of the test_run() function.
>
> This would cause the synchronization to happen for the test you put it in.  This will work
> if you have a pre-determined set of tests.  You could add this line to
> the first test your run after rebooting.  Or you could make a test specifically to perform
> this operation, and run it before other tests.
>
> If you want to perform the time synchronization for every test, then there are ways to
> add this to an overlay function, and trigger it using a special value for DISTRIB in the
> board file.
>
> This is a bit complicated, but let me know if you'd like to do this, and I'll write some
> instructions.
>
> I hope this helps.
>  -- Tim


[-- Attachment #2: Type: text/html, Size: 6250 bytes --]

Re: [Fuego] Time sync

[Bird, Tim]

> -----Original Message-----
> From: Muk Anc <muk.anc@outlook.com>
> 
...
> I would also like to pose another question while we are at it.
> 
> I have an ADC on our DUT. I would like to read this ADC every second while a batch test is running. The batch test runs around 20 individual
> tests. I would like to start reading this ADC and show its readings on the console (I use the FTC command to trigger the batch test) at the
> beginning of the first sub test, and stop when the batch test finishes, either successfully or due to a failure of a sub test.
> 
> Currently, I have updated a few of the subtest's test script to additionally read the ADC and echo the output, but I can do this only for tests
> that run for a long period of time, e.g. memtest. While memtest is running in the background, I keep reading and outputting the ADC every
> second. What would be the best way to decouple this?

I have a few questions that may help me recommend an appropriate solution.

Where would you like the stream of values of the ADC reported?  Do you want to see them interleaved with
the test output for the sub-tests of the batch test, or would it be sufficient to collect them into a file at the
end, and just emit the list of ADC values?  You could possibly timestamp them on the target in order to
do post-processing to correlate the values with the test executions, if they are somehow related.

Or, you could do both - both emit them and simultaneously put them to a file on the target.

If you want a long-running process to execute and collect data while other things are happening
on the target, then I might have some code that would be useful for you.  Some years ago I started
work on a parallel task feature to allow for multiple tests to execute at the same time on a board.
The intent was to allow for doing things like measuring power, or doing filesystem benchmarks, while
executing a stress workload on the board.   I'll have to see if I can find this work, which I shelved, but
which might work for your requirements.

The aspect of getting the results into either the console log of the batch test, or into the testlogs of
the Fuego sub-tests, is a bit trickier.  Let me know if that's what you have in mind, and we can discuss
options.

 -- Tim