diff --git a/configs/sama5d3-xplained/README.txt b/configs/sama5d3-xplained/README.txt index aa5f04129e..8683bd0934 100644 --- a/configs/sama5d3-xplained/README.txt +++ b/configs/sama5d3-xplained/README.txt @@ -2539,16 +2539,35 @@ Tickless OS timing using the RC clock! UPDATE: This will now be selected by default when you configure for TICKLESS support. - The slow clock has a resolution of about 30.518 microseconds. Ideally, the - value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock - resolution. Otherwise there will be cumulative timing inaccuracies. A + The slow clock has a resolution of about 30.518 microseconds. Ideally, + the value of CONFIG_USEC_PER_TICK should be the exact clock resolution. + Otherwise there will be cumulative timing inaccuracies. But a choice choice of: - CONFIG_USEC_PER_TICK=61, or - CONFIG_USEC_PER_TICK=122 + CONFIG_USEC_PER_TICK=31 - will be close but will still have inaccuracies that will effect the time - due to long term error build-up. + will have an error of 0.6% and will have inaccuracies that will + effect the time due to long term error build-up. + + UPDATE: As of this writing (2015-12-03), the Tickless support is + functional. However, there are inaccuracies in delays. For example, + + nsh> sleep 10 + + results in a delay of maybe 5.4 seconds. But the timing accuracy is + correct if all competing uses of the interval timer are disabled (mostly + from the high priority work queue). Therefore, I conclude that this + inaccuracy is due to the inaccuracies in the representation of the clock + rate. 30.518 usec cannot be represented accurately. Each timing + calculation results in a small error. When the interval timer is very + busy, long delays will be divided into many small pieces and each small + piece has a large error in the calculation. The cumulative error is the + cause of the problem. + + Solution: 30.518 microseconds is not representable and the value of + CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off + long delays (short delays are probably still okay). We should driver + the interval timer with PCK6 with a period that is exactly representable. SAMA5 Timer Usage ----------------- diff --git a/configs/sama5d3x-ek/README.txt b/configs/sama5d3x-ek/README.txt index 0e9fca1e43..593a811c5c 100644 --- a/configs/sama5d3x-ek/README.txt +++ b/configs/sama5d3x-ek/README.txt @@ -2859,16 +2859,35 @@ Tickless OS timing using the RC clock! UPDATE: This will now be selected by default when you configure for TICKLESS support. - The slow clock has a resolution of about 30.518 microseconds. Ideally, the - value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock - resolution. Otherwise there will be cumulative timing inaccuracies. A + The slow clock has a resolution of about 30.518 microseconds. Ideally, + the value of CONFIG_USEC_PER_TICK should be the exact clock resolution. + Otherwise there will be cumulative timing inaccuracies. But a choice choice of: - CONFIG_USEC_PER_TICK=61, or - CONFIG_USEC_PER_TICK=122 + CONFIG_USEC_PER_TICK=31 - will be close but will still have inaccuracies that will effect the time - due to long term error build-up. + will have an error of 0.6% and will have inaccuracies that will + effect the time due to long term error build-up. + + UPDATE: As of this writing (2015-12-03), the Tickless support is + functional. However, there are inaccuracies in delays. For example, + + nsh> sleep 10 + + results in a delay of maybe 5.4 seconds. But the timing accuracy is + correct if all competing uses of the interval timer are disabled (mostly + from the high priority work queue). Therefore, I conclude that this + inaccuracy is due to the inaccuracies in the representation of the clock + rate. 30.518 usec cannot be represented accurately. Each timing + calculation results in a small error. When the interval timer is very + busy, long delays will be divided into many small pieces and each small + piece has a large error in the calculation. The cumulative error is the + cause of the problem. + + Solution: 30.518 microseconds is not representable and the value of + CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off + long delays (short delays are probably still okay). We should driver + the interval timer with PCK6 with a period that is exactly representable. SAMA5 Timer Usage ----------------- diff --git a/configs/sama5d4-ek/README.txt b/configs/sama5d4-ek/README.txt index fcf3ae98e7..8a6b69a6d1 100644 --- a/configs/sama5d4-ek/README.txt +++ b/configs/sama5d4-ek/README.txt @@ -3367,22 +3367,35 @@ Tickless OS timing using the RC clock! UPDATE: This will now be selected by default when you configure for TICKLESS support. - The slow clock has a resolution of about 30.518 microseconds. Ideally, the - value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock - resolution. Otherwise there will be cumulative timing inaccuracies. A + The slow clock has a resolution of about 30.518 microseconds. Ideally, + the value of CONFIG_USEC_PER_TICK should be the exact clock resolution. + Otherwise there will be cumulative timing inaccuracies. But a choice choice of: - CONFIG_USEC_PER_TICK=61, or - CONFIG_USEC_PER_TICK=122 + CONFIG_USEC_PER_TICK=31 - will be close but will still have inaccuracies that will effect the time - due to long term error build-up. + will have an error of 0.6% and will have inaccuracies that will + effect the time due to long term error build-up. - UPDATE: As of this writing (2014-8-11), the Tickless support is - functional. However, the timing for all delays appears to be half the - duration that it should be. I don't see anything wrong with the setup - and I am suspecting that there may be something I don't understand about - the counting frequency. + UPDATE: As of this writing (2015-12-03), the Tickless support is + functional. However, there are inaccuracies in delays. For example, + + nsh> sleep 10 + + results in a delay of maybe 5.4 seconds. But the timing accuracy is + correct if all competing uses of the interval timer are disabled (mostly + from the high priority work queue). Therefore, I conclude that this + inaccuracy is due to the inaccuracies in the representation of the clock + rate. 30.518 usec cannot be represented accurately. Each timing + calculation results in a small error. When the interval timer is very + busy, long delays will be divided into many small pieces and each small + piece has a large error in the calculation. The cumulative error is the + cause of the problem. + + Solution: 30.518 microseconds is not representable and the value of + CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off + long delays (short delays are probably still okay). We should driver + the interval timer with PCK6 with a period that is exactly representable. SAMA5 Timer Usage ----------------- diff --git a/configs/same70-xplained/README.txt b/configs/same70-xplained/README.txt index 00309ac7fa..3cfe620835 100644 --- a/configs/same70-xplained/README.txt +++ b/configs/same70-xplained/README.txt @@ -911,22 +911,35 @@ Tickless OS definition BOARD_HAVE_SLOWXTAL in the configs/same70-xplained/board.h file. - The slow clock has a resolution of about 30.518 microseconds. Ideally, the - value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock - resolution. Otherwise there will be cumulative timing inaccuracies. A + The slow clock has a resolution of about 30.518 microseconds. Ideally, + the value of CONFIG_USEC_PER_TICK should be the exact clock resolution. + Otherwise there will be cumulative timing inaccuracies. But a choice choice of: - CONFIG_USEC_PER_TICK=61, or - CONFIG_USEC_PER_TICK=122 + CONFIG_USEC_PER_TICK=31 - will be close but will still have inaccuracies that will effect the time - due to long term error build-up. + will have an error of 0.6% and will have inaccuracies that will + effect the time due to long term error build-up. - UPDATE: As of this writing (2015-12-02), the Tickless support is - functional. However, the timing for all delays appears to be half the - duration that it should be. I don't see anything wrong with the setup - and I am suspecting that there may be something I don't understand about - the counting frequency. + UPDATE: As of this writing (2015-12-03), the Tickless support is + functional. However, there are inaccuracies in delays. For example, + + nsh> sleep 10 + + results in a delay of maybe 5.4 seconds. But the timing accuracy is + correct if all competing uses of the interval timer are disabled (mostly + from the high priority work queue). Therefore, I conclude that this + inaccuracy is due to the inaccuracies in the representation of the clock + rate. 30.518 usec cannot be represented accurately. Each timing + calculation results in a small error. When the interval timer is very + busy, long delays will be divided into many small pieces and each small + piece has a large error in the calculation. The cumulative error is the + cause of the problem. + + Solution: 30.518 microseconds is not representable and the value of + CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off + long delays (short delays are probably still okay). We should driver + the interval timer with PCK6 with a period that is exactly representable. SAME70 Timer Usage ------------------ diff --git a/configs/samv71-xult/README.txt b/configs/samv71-xult/README.txt index 498132ab1a..0f94108feb 100644 --- a/configs/samv71-xult/README.txt +++ b/configs/samv71-xult/README.txt @@ -1496,22 +1496,35 @@ Tickless OS input. The 32.768KHz crystal is selected by the definition BOARD_HAVE_SLOWXTAL in the configs/samv71-xult/board.h file. - The slow clock has a resolution of about 30.518 microseconds. Ideally, the - value of CONFIG_USEC_PER_TICK should be an exact multiple of the clock - resolution. Otherwise there will be cumulative timing inaccuracies. A + The slow clock has a resolution of about 30.518 microseconds. Ideally, + the value of CONFIG_USEC_PER_TICK should be the exact clock resolution. + Otherwise there will be cumulative timing inaccuracies. But a choice choice of: - CONFIG_USEC_PER_TICK=61, or - CONFIG_USEC_PER_TICK=122 + CONFIG_USEC_PER_TICK=31 - will be close but will still have inaccuracies that will effect the time - due to long term error build-up. + will have an error of 0.6% and will have inaccuracies that will + effect the time due to long term error build-up. - UPDATE: As of this writing (2015-12-02), the Tickless support is - functional. However, the timing for all delays appears to be half the - duration that it should be. I don't see anything wrong with the setup - and I am suspecting that there may be something I don't understand about - the counting frequency. + UPDATE: As of this writing (2015-12-03), the Tickless support is + functional. However, there are inaccuracies in delays. For example, + + nsh> sleep 10 + + results in a delay of maybe 5.4 seconds. But the timing accuracy is + correct if all competing uses of the interval timer are disabled (mostly + from the high priority work queue). Therefore, I conclude that this + inaccuracy is due to the inaccuracies in the representation of the clock + rate. 30.518 usec cannot be represented accurately. Each timing + calculation results in a small error. When the interval timer is very + busy, long delays will be divided into many small pieces and each small + piece has a large error in the calculation. The cumulative error is the + cause of the problem. + + Solution: 30.518 microseconds is not representable and the value of + CONFIG_USEC_PER_SEC is too inaccurate; error build-up is throwing off + long delays (short delays are probably still okay). We should driver + the interval timer with PCK6 with a period that is exactly representable. SAMV7 Timer Usage -----------------