From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F5FF1A9FBC for ; Wed, 20 May 2026 01:01:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779238911; cv=none; b=uy6Sq7Fc0ryNAQKZOm3kjUbnuJJtvPK5ht9TRDvr7OdlNyBuJo1DTLvil+B+35CLkgEGN+TrQ2VdKFlkjkKvFIpaznCXV+yB5BhEJDH9oUJtUpjjbuOAfdO0cVvUm+CE/AfYrDNzXCvxhi3xi0Nx65CZevCqUG/27XoDqWV2U+w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779238911; c=relaxed/simple; bh=B3/+C0UBovQWfrrt2xmKixuA9VRQs8ZwGAiWikuQoLY=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=V9PphzGwXjOO3+fKJNhv3a31g8Ewhu3SpviozDN6clEC1yjRFcGou4iEpXlStfTk5Q4Sbob8uSKWBiRg6a80YrcAOTsnwnTeW0h/igeM3E8/eX9sp7cqgybjxj7YfGhTPhsty0SLj8cbW61ZRZ1QLeW9gnpYOyfSu0EDTRRJb/I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=casper.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=eJRpDt1+; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=casper.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="eJRpDt1+" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=MIME-Version:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=OXNpOOoo0MGBu+ZVPL2dJo/OznabmTQrAwmYVDKxNP4=; b=eJRpDt1+VOe3tNeVwA6/S+guST 1uMa7FlYY0IXWS6i2wMXS5c0qfv2RwnTggNbUXEfncRnCppexwnr5EJ4xbwoezVAWGIZ68hgB3AnS VKIAfIDRFloy9uFi/u1pJtk1jU9Im/m+jEM9LG5gtSFxy+4++DmQwzjJaVaBj73jR/U0v/sfBYUVn esFg8Re6mB+SHNP5yiypBv0SbXD+M3e+J61DPdTL+HKXkUA3FD+5ls9GYlRf7inLU+1QW1kjARFqr vIzkHuUrv2nvDn+pjt0AK+HpD51cN1Joi15/S1ixLl/jbL+suHAH5/LQ7yEK31SL00CxodQc3h36H 4s0bEJAA==; Received: from [172.31.31.148] (helo=u09cd745991455d.lumleys.internal) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wPVJc-00000006Z4P-3LC2; Wed, 20 May 2026 01:01:41 +0000 Message-ID: Subject: Re: [RFC PATCH 1/4] timekeeping: Remove xtime_remainder from ntp_error accumulation From: David Woodhouse To: John Stultz Cc: Miroslav Lichvar , Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Thomas Gleixner , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?ISO-8859-1?Q?Wei=DFschuh?= , Arnd Bergmann , linux-kernel@vger.kernel.org Date: Wed, 20 May 2026 02:01:40 +0100 In-Reply-To: References: <20260513210157.3410814-1-dwmw2@infradead.org> <20260513210157.3410814-2-dwmw2@infradead.org> <5b8a8117a5c45482a515d9fcf026b2a1ae7c5176.camel@infradead.org> <112efe3ec75c3a0bf3ea9d53034a7dea9bd553c7.camel@infradead.org> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/pkcs7-signature"; boundary="=-4bwGNDc0sd1ScRXUL1ZZ" User-Agent: Evolution 3.52.3-0ubuntu1.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html --=-4bwGNDc0sd1ScRXUL1ZZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2026-05-19 at 17:01 -0700, John Stultz wrote: > On Tue, May 19, 2026 at 3:18=E2=80=AFPM David Woodhouse wrote: > >=20 > > On Tue, 2026-05-19 at 14:54 -0700, John Stultz wrote: > > >=20 > > > > By simply adding ntp_interval and then subtracting the correct curr= ent > > > > value of xtime_interval, logarithmic_accumulation doesn't *need* a > > > > separate variable which tracks that delta. I don't quite understand= why > > > > it ever did add it in the first place. > > >=20 > > > Again, it's due to the error caused by the granularity of the > > > clocksource (against the HZ interval).=C2=A0 That initial delta will > > > otherwise cause an accurate clock to get erroniously steered either > > > faster or slower when no NTP adjustments being made.=C2=A0 The subtra= cting > > > of that remainder is just trying to compensate for this base error. > >=20 > > I must be confused. We *are* subtracting that remainder, not ignoring > > it. > >=20 > > The value of xtime_remainder was (tick_length - xtime_interval). It's > > the discrepancy between the distance we *want* the clock to move in a > > single tick, and the distance it *does* move in a single tick at a > > given value of 'mult'. > >=20 > > So we add tick_length, and we subtract xtime_interval. Thus adjusting > > ntp_error by the difference between them. > >=20 > > I don't understand why the old code was then *also* subtracting a stale > > value of xtime_remainder which had been calculated at boot time. > >=20 > > Am I missing something here? >=20 > Hrm. Apologies, I fret I'm just repeating myself, and I'm not sure how > to reconceptualize my point to be more helpful. :/ >=20 > But you skipped my question in my last mail, which I do think will help: > * If there is no adjustment being made, why would there be a > difference between the initial ntp_interval and the initial > xtime_interval? Because the ntp_interval is not a precisely multiple of the cycle period? The example I've been working with all week is 1ms tick, 2400MHz TSC. So that is 1000000<<24 "shifted nanoseconds", or 16777216000000, divided by 2400000 to give a 'mult' value of 6990506.667. Truncated to an integer, that's 6990506, giving an xtime_interval of=20 16777214400000 and xtime_remainder of 1600000. The dithering will do a duty cycle of one tick at 6990506 to two ticks at 6990507, to achieve the overall desired rate. > * Why would it exist? And if it does exist, what does it represent? It represents the difference between the xtime *actually* added during a tick (xtime_interval), and the time we *wanted* to add during a tick (ntp_interval). > * And if the frequency (cyc2ns) is correct, and no adjustment is being > made, is it not erroneous to be adjusting the clock to correct for > this accumulating delta? I don't think it does accumulate in that state, does it? It sawtooths around zero as we dither between mult and mult+1. And in my example, over the course of *three* ticks it'll reach zero again, as 3*ntp_interval =3D=3D 2*xtime_interval(mult+1) + 1*xtime_interval(mult) > Maybe does it help to thinking of it it as quantization error from a > single cycle length? And how it may not be able to match the > tick_length at various HZ? Right. Because it's all about the *fractional* part of 'mult'. > But the quantization error doesn't have anything to do with the > accuracy of that cycle length.=C2=A0 Right. That part is purely about arithmetic precision. > But if not accounted for, that error accumulates in ntp_error and > results in unwanted frequency adjustments. Right. If ntp_error doesn't account for xtime_remainder each tick (or more accurately, by +ntp_interval-xtime_interval), then errors will accumulate and result in *effective* frequency adjustments because the 'mult' dithering will not follow the duty cycle that it should, and xtime will not advance at the correct rate. And since NTP works on a feedback loop, that in turn will result in *actual* frequency adjustments (and alterations to tick_length) because NTP will interpret the error-induced drift as the underlying oscillator going faster/slower. >=20 > > I've updated the commit message: > > https://git.infradead.org/?p=3Dusers/dwmw2/linux.git;a=3Dcommitdiff;h= =3D459ebaef612 > >=20 > > > Now, it is imperfect because it's a constant adjustment and not > > > proportioned to the NTP adjustments that might be later made. > > >=20 > > > And clearly there is some issue as you're having problems with it > > > using a fine-grained clocksource like the TSC where it really > > > shouldn't be a major factor. > >=20 > > None of it matters if you have NTP running and constantly re-adjusting > > your clock. You can have a +50PPM drift through errors in the tracking, > > and NTP will just assume your oscillator is running 50PPM fast and > > adjust accordingly. > >=20 > > But when you set the kernel to follow a precise y=3Dmx+c line for the T= SC > > to real time conversion and *expect* it to do as it's told while > > tracking the divergence to the nanosecond... all counters are course- > > grained :) >=20 > Something maybe as an alternative approach: > What if instead of tinkering with the xtime_remainder separately, we > just made the adjustment to the initial ntp_interval (propagated to > the tk->ntp_tick) to handle the granularity error? This would maybe > more intuitively address the conceptual "what the ntp machinery wants > time to be" issue? Does that help? Aren't we continuously adjusting the tick_length because that's how we accommodate actual frequency changes of the counter? > Though we'd need to propagate that out to the ntp.c logic so it would > show up in ntp_tick_length() (and maybe even further up into > tick_usec). But then I worry the ntp userland might blindly overwrite > this on startup, so maybe this approach won't work. >=20 > Another thing to consider: we could maybe use some threshold for > applying the granularity error correction, so we only apply the > correction when the clocksource is coarse and the error is large > enough to warrant it? I'm still lost. What's the problem we're trying to solve here now? AIUI the granularity error correction is simple; we add tick_length and subtract xtime_interval, which is basically equivalent to adding the *correct* value of xtime_remainder each tick. It's what this code was always trying to do; it just got it wrong. Now it's fixed, why would we only do it *sometimes*?=20 This tracking is precisely what ensures that the dithering picks 'mult' vs. 'mult+1' in the right duty cycle. It's not just for coarse clocksources; even my 2400MHz TSC will lose ~95ns/s if we don't track this. --=-4bwGNDc0sd1ScRXUL1ZZ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD9Aw ggSOMIIDdqADAgECAhAOmiw0ECVD4cWj5DqVrT9PMA0GCSqGSIb3DQEBCwUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0yNDAxMzAwMDAwMDBaFw0zMTEx MDkyMzU5NTlaMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYDVQQDExdWZXJv a2V5IFNlY3VyZSBFbWFpbCBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMjvgLKj jfhCFqxYyRiW8g3cNFAvltDbK5AzcOaR7yVzVGadr4YcCVxjKrEJOgi7WEOH8rUgCNB5cTD8N/Et GfZI+LGqSv0YtNa54T9D1AWJy08ZKkWvfGGIXN9UFAPMJ6OLLH/UUEgFa+7KlrEvMUupDFGnnR06 aDJAwtycb8yXtILj+TvfhLFhafxroXrflspavejQkEiHjNjtHnwbZ+o43g0/yxjwnarGI3kgcak7 nnI9/8Lqpq79tLHYwLajotwLiGTB71AGN5xK+tzB+D4eN9lXayrjcszgbOv2ZCgzExQUAIt98mre 8EggKs9mwtEuKAhYBIP/0K6WsoMnQCcCAwEAAaOCAVwwggFYMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFIlICOogTndrhuWByNfhjWSEf/xwMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6en IZ3zbcgPMA4GA1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIweQYI KwYBBQUHAQEEbTBrMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQwYIKwYB BQUHMAKGN2h0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RD QS5jcnQwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 QXNzdXJlZElEUm9vdENBLmNybDARBgNVHSAECjAIMAYGBFUdIAAwDQYJKoZIhvcNAQELBQADggEB ACiagCqvNVxOfSd0uYfJMiZsOEBXAKIR/kpqRp2YCfrP4Tz7fJogYN4fxNAw7iy/bPZcvpVCfe/H /CCcp3alXL0I8M/rnEnRlv8ItY4MEF+2T/MkdXI3u1vHy3ua8SxBM8eT9LBQokHZxGUX51cE0kwa uEOZ+PonVIOnMjuLp29kcNOVnzf8DGKiek+cT51FvGRjV6LbaxXOm2P47/aiaXrDD5O0RF5SiPo6 xD1/ClkCETyyEAE5LRJlXtx288R598koyFcwCSXijeVcRvBB1cNOLEbg7RMSw1AGq14fNe2cH1HG W7xyduY/ydQt6gv5r21mDOQ5SaZSWC/ZRfLDuEYwggWbMIIEg6ADAgECAhAH5JEPagNRXYDiRPdl c1vgMA0GCSqGSIb3DQEBCwUAMEExCzAJBgNVBAYTAkFVMRAwDgYDVQQKEwdWZXJva2V5MSAwHgYD VQQDExdWZXJva2V5IFNlY3VyZSBFbWFpbCBHMjAeFw0yNDEyMzAwMDAwMDBaFw0yODAxMDQyMzU5 NTlaMB4xHDAaBgNVBAMME2R3bXcyQGluZnJhZGVhZC5vcmcwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDali7HveR1thexYXx/W7oMk/3Wpyppl62zJ8+RmTQH4yZeYAS/SRV6zmfXlXaZ sNOE6emg8WXLRS6BA70liot+u0O0oPnIvnx+CsMH0PD4tCKSCsdp+XphIJ2zkC9S7/yHDYnqegqt w4smkqUqf0WX/ggH1Dckh0vHlpoS1OoxqUg+ocU6WCsnuz5q5rzFsHxhD1qGpgFdZEk2/c//ZvUN i12vPWipk8TcJwHw9zoZ/ZrVNybpMCC0THsJ/UEVyuyszPtNYeYZAhOJ41vav1RhZJzYan4a1gU0 kKBPQklcpQEhq48woEu15isvwWh9/+5jjh0L+YNaN0I//nHSp6U9COUG9Z0cvnO8FM6PTqsnSbcc 0j+GchwOHRC7aP2t5v2stVx3KbptaYEzi4MQHxm/0+HQpMEVLLUiizJqS4PWPU6zfQTOMZ9uLQRR ci+c5xhtMEBszlQDOvEQcyEG+hc++fH47K+MmZz21bFNfoBxLP6bjR6xtPXtREF5lLXxp+CJ6KKS blPKeVRg/UtyJHeFKAZXO8Zeco7TZUMVHmK0ZZ1EpnZbnAhKE19Z+FJrQPQrlR0gO3lBzuyPPArV hvWxjlO7S4DmaEhLzarWi/ze7EGwWSuI2eEa/8zU0INUsGI4ywe7vepQz7IqaAovAX0d+f1YjbmC VsAwjhLmveFjNwIDAQABo4IBsDCCAawwHwYDVR0jBBgwFoAUiUgI6iBOd2uG5YHI1+GNZIR//HAw HQYDVR0OBBYEFFxiGptwbOfWOtMk5loHw7uqWUOnMDAGA1UdEQQpMCeBE2R3bXcyQGluZnJhZGVh ZC5vcmeBEGRhdmlkQHdvb2Rob3Uuc2UwFAYDVR0gBA0wCzAJBgdngQwBBQEBMA4GA1UdDwEB/wQE AwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwewYDVR0fBHQwcjA3oDWgM4YxaHR0 cDovL2NybDMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDA3oDWgM4YxaHR0 cDovL2NybDQuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNybDB2BggrBgEFBQcB AQRqMGgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBABggrBgEFBQcwAoY0 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL1Zlcm9rZXlTZWN1cmVFbWFpbEcyLmNydDANBgkq hkiG9w0BAQsFAAOCAQEAQXc4FPiPLRnTDvmOABEzkIumojfZAe5SlnuQoeFUfi+LsWCKiB8Uextv iBAvboKhLuN6eG/NC6WOzOCppn4mkQxRkOdLNThwMHW0d19jrZFEKtEG/epZ/hw/DdScTuZ2m7im 8ppItAT6GXD3aPhXkXnJpC/zTs85uNSQR64cEcBFjjoQDuSsTeJ5DAWf8EMyhMuD8pcbqx5kRvyt JPsWBQzv1Dsdv2LDPLNd/JUKhHSgr7nbUr4+aAP2PHTXGcEBh8lTeYea9p4d5k969pe0OHYMV5aL xERqTagmSetuIwolkAuBCzA9vulg8Y49Nz2zrpUGfKGOD0FMqenYxdJHgDCCBZswggSDoAMCAQIC EAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQELBQAwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoT B1Zlcm9rZXkxIDAeBgNVBAMTF1Zlcm9rZXkgU2VjdXJlIEVtYWlsIEcyMB4XDTI0MTIzMDAwMDAw MFoXDTI4MDEwNDIzNTk1OVowHjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBANqWLse95HW2F7FhfH9bugyT/danKmmXrbMnz5GZNAfj Jl5gBL9JFXrOZ9eVdpmw04Tp6aDxZctFLoEDvSWKi367Q7Sg+ci+fH4KwwfQ8Pi0IpIKx2n5emEg nbOQL1Lv/IcNiep6Cq3DiyaSpSp/RZf+CAfUNySHS8eWmhLU6jGpSD6hxTpYKye7PmrmvMWwfGEP WoamAV1kSTb9z/9m9Q2LXa89aKmTxNwnAfD3Ohn9mtU3JukwILRMewn9QRXK7KzM+01h5hkCE4nj W9q/VGFknNhqfhrWBTSQoE9CSVylASGrjzCgS7XmKy/BaH3/7mOOHQv5g1o3Qj/+cdKnpT0I5Qb1 nRy+c7wUzo9OqydJtxzSP4ZyHA4dELto/a3m/ay1XHcpum1pgTOLgxAfGb/T4dCkwRUstSKLMmpL g9Y9TrN9BM4xn24tBFFyL5znGG0wQGzOVAM68RBzIQb6Fz758fjsr4yZnPbVsU1+gHEs/puNHrG0 9e1EQXmUtfGn4InoopJuU8p5VGD9S3Ikd4UoBlc7xl5yjtNlQxUeYrRlnUSmdlucCEoTX1n4UmtA 9CuVHSA7eUHO7I88CtWG9bGOU7tLgOZoSEvNqtaL/N7sQbBZK4jZ4Rr/zNTQg1SwYjjLB7u96lDP sipoCi8BfR35/ViNuYJWwDCOEua94WM3AgMBAAGjggGwMIIBrDAfBgNVHSMEGDAWgBSJSAjqIE53 a4blgcjX4Y1khH/8cDAdBgNVHQ4EFgQUXGIam3Bs59Y60yTmWgfDu6pZQ6cwMAYDVR0RBCkwJ4ET ZHdtdzJAaW5mcmFkZWFkLm9yZ4EQZGF2aWRAd29vZGhvdS5zZTAUBgNVHSAEDTALMAkGB2eBDAEF AQEwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDB7BgNVHR8E dDByMDegNaAzhjFodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu Y3JsMDegNaAzhjFodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVtYWlsRzIu Y3JsMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vVmVyb2tleVNlY3VyZUVt YWlsRzIuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQBBdzgU+I8tGdMO+Y4AETOQi6aiN9kB7lKWe5Ch 4VR+L4uxYIqIHxR7G2+IEC9ugqEu43p4b80LpY7M4KmmfiaRDFGQ50s1OHAwdbR3X2OtkUQq0Qb9 6ln+HD8N1JxO5nabuKbymki0BPoZcPdo+FeRecmkL/NOzzm41JBHrhwRwEWOOhAO5KxN4nkMBZ/w QzKEy4PylxurHmRG/K0k+xYFDO/UOx2/YsM8s138lQqEdKCvudtSvj5oA/Y8dNcZwQGHyVN5h5r2 nh3mT3r2l7Q4dgxXlovERGpNqCZJ624jCiWQC4ELMD2+6WDxjj03PbOulQZ8oY4PQUyp6djF0keA MYIDuzCCA7cCAQEwVTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMX VmVyb2tleSBTZWN1cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJYIZIAWUDBAIBBQCg ggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI2MDUyMDAxMDE0 MFowLwYJKoZIhvcNAQkEMSIEIAptMW2bEgZ2E3YvdseSHbCSJ9yxlm2ZA81aA+MBGN6VMGQGCSsG AQQBgjcQBDFXMFUwQTELMAkGA1UEBhMCQVUxEDAOBgNVBAoTB1Zlcm9rZXkxIDAeBgNVBAMTF1Zl cm9rZXkgU2VjdXJlIEVtYWlsIEcyAhAH5JEPagNRXYDiRPdlc1vgMGYGCyqGSIb3DQEJEAILMVeg VTBBMQswCQYDVQQGEwJBVTEQMA4GA1UEChMHVmVyb2tleTEgMB4GA1UEAxMXVmVyb2tleSBTZWN1 cmUgRW1haWwgRzICEAfkkQ9qA1FdgOJE92VzW+AwDQYJKoZIhvcNAQEBBQAEggIAFBqF5Yf8UdaF ribyVAPB5OTFGG0YO8HUJ229cxlrgkegRcPiuD14SxeC9ubta2TDBg+N+BznqfuyIAVffj+lOU+P o0JIIX3RJydnbfnbahhD3gB3k4Kw/MC4u1JiIss8fH3cNVh+Xu09T/TIP5watdTUWZl6qHuDjVaM LwhRULQ85zBz+iTN0JtZRAHjlSVpYbHcT8BrrpYJTphp+4iheBUs4GIppkRrjR/kYaZEEOZuiGVS eBz7hVAjh+pXDpIrUUehUSQGqjIkTtcVPDqccGdysvNq+8Q71bAIKdns339WD2knrMZHW713btvg uZ2J6puqAa5/XToC3DdZnTQRLG5EueOTtc0KTHNvGuQv+kSWzhGSh60Ksfpq2pNwhidUfSa70edp lm55vRbMFm3CiBcNmIm46Rh41YmoHdXcyGjWQj4qbj1/lWoF+CwUlvRvTZrXf4sL+mu2oD2EA/NK DkvsXbSo+BooxyYhUD5foW7SKOaFJu15SGzFwZSEexBaoTrR3G1Lu5NEWw+NTwjqPo7lDz6hOTyz C4+xLf0r9zX/eOPea3MM/J5zqStpJJ+dhpV1Y88TwAkPz46FeJBs+Y+jjiKs7Y9luMIVel3BwG+1 Ys+L2UMZGkQlgVdYYq+WPZDzlyMLw7PD+m8SXA/i+dGCG4PkaCVaUGkEq3Pjh4AAAAAAAAA= --=-4bwGNDc0sd1ScRXUL1ZZ--