From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F140E3CB37 for ; Thu, 11 Jan 2024 12:29:43 -0500 (EST) Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-58e256505f7so2793653eaf.3 for ; Thu, 11 Jan 2024 09:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; t=1704994183; x=1705598983; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TT2mRMgmTiDr4pHjKrpqDCuavPMBb0ByAhIf7UmYVOU=; b=QGTVEMx5crH+rnuRtB34KQLlFhr7Jk2Y3If3Yh1Ip/0k6CiWi1l4zQx4JGqGoIgDGN ln1kw2G4xyP4Nw3gv4biDt0l6DeEfksmlqqzG35JmbNHrL5XUopFWRhLgOZnUP8x3ZzX 1NLTsKTkzdMnOOyeIVXFGhP6TdX9LwBAhyhMA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704994183; x=1705598983; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TT2mRMgmTiDr4pHjKrpqDCuavPMBb0ByAhIf7UmYVOU=; b=JsiricBV5GP26H2FgD1I/hzlJFmgOIJ2kRQt3U7tjr1ql150eTgEJtpjvkeoPuX5Fg h/pLqDFcNq9kIWEIDq1StgP4StT3qMvvjl70NU4PmdCBmc2YEKbE+I13J6wQtG16WyCb 9KyDbPzOzCbwlMA8olUFFamWf5Os9oZkW68il+kmSsIWkrJIOctbO4gbIM6W7KsgOxT7 y+Zl5hdzpLoA5DfuFN+69HTQ+J6vr2bAsLLMdXzOiZu0eNckqUOU18wg02TdDr5OWFJR 1eXLDocgVrHypyG3E3FO5l/Tk38Le60ypy7Zv5EpA1bDVBfVre/9Cs+JnrQrhv0f0eVw uyrg== X-Gm-Message-State: AOJu0YzJ84U4ICaCVRWKVHI5yMYfDx9Dd4hJPALtzl9AiljJqxU6poK6 w4YzJT1vZEIroAyeDxjX4YU4t9td84NSs3TWyH3QlA4bwGarNp3dRxRdMty0IYSEEQ+rjLqK1wI B+BhO7RzzyNmps9H16TKZOJknY0p6UCmOYi0sdhohxSnX5NpQ3gH0f6X6t04= X-Google-Smtp-Source: AGHT+IEm11mqL3uiVKx4XqeTKvoBGLGUvodUHZ6dbv8Nkdn8sVJW0hR3t+f6LtXudnRC0qa17BhahqpwwMURXvQoY1w= X-Received: by 2002:a4a:1781:0:b0:594:26c9:5537 with SMTP id 123-20020a4a1781000000b0059426c95537mr174014ooe.6.1704994182854; Thu, 11 Jan 2024 09:29:42 -0800 (PST) MIME-Version: 1.0 References: <877cki4vxq.fsf@toke.dk> <875y01xwi5.fsf@toke.dk> In-Reply-To: From: Bob McMahon Date: Thu, 11 Jan 2024 09:29:30 -0800 Message-ID: To: Dave Taht Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Make-Wifi-fast Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a4defe060eaee4c8" Subject: Re: [Make-wifi-fast] a cheer up tweet for y'all X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2024 17:29:44 -0000 --000000000000a4defe060eaee4c8 Content-Type: multipart/alternative; boundary="0000000000009d29f3060eaee415" --0000000000009d29f3060eaee415 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I perceive a few major issues per this analysis: - This is still a sun workstation model - ditch the SoC, BSD & things like DMAs and see what comes out on the other side. Build a switch and/o= r transceivers - 802.11 standards set the road maps which is much about spectrum efficiency so that's the direction - Open-source sw engineers have zero visibility into hw engineering actuals so are woefully out of date (though it's understandable because = the way things are structured doesn't expose the state of engineering in a public manner) - I think we need an e2e low-latency technical offering. Not sure why there has been so much misinformation around this but it hasn't seemed t= o help Bob On Thu, Jan 11, 2024, 1:31 AM Dave Taht wrote: > i so wish more of what I discussed 8 years ago, had made it to the > chipmakers. Minstrel-blues, in the end, didn't work out, but seemed so > promising (coupled rate and power control). > https://www.youtube.com/watch?v=3DRb-UnHDw02o&t=3D1041s > > On Wed, Jan 10, 2024 at 1:23=E2=80=AFPM Bob McMahon > wrote: > > > > > Well, the original context of the question was "Linux WiFi drivers ar= e > > > terrible, what can we do about that", and, well, providing proper > > > upstream drivers at HW launch is the way to solve that. > > > > This is out of the scope of chip makers for modern chips. The os driver= s > are written by system integrators - specialization has divided these task= s. > Chip makers don't affect open vs closed source drivers of systems. Think > of a WiFi chip now as transistors with a small microcontroller and not a > linux NIC. > > Mediatek has had an "Upstream first" wifi chipset development policy > for many years now, the mt76 got competetive and the mt79 is looking > really good. It has a very minimal blob attached to it, and a decent > API (with a couple exceptions). > > The offloaded cpu in the ath10k was actually quite powerful, and had > that code been more commonly available, it would not have taken so > many years and a mere *one* guy licensed to work on it, to get the > ath10k firmware up to snuff. > > https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002 > > The R/T OS on that "microcontroller" was a nightmare of spaghetti > written by EEs on crack. > > I quiver in fear about even less open firmware blobs than that. > > > > One can argue that chip makers don't provide documents to open-source > developers, which is mostly accurate. But documents aren't the blocker. > > Oh, they are key to understanding what the chip can be made to do > outside of the scope of the original designers. > > > I think an open source community would have to innovate to a level to > drive the use of chips coming off a foundry line for a chip maker to > consider assigning resources to support open-source teams. Old chips with > 10+ year old NRE doesn't justify any investment by anyone. > > I would merely like a competent OS developer to be present from day > one of a new or being revised design to provide useful feedback from > the field about what ideas are BS and which are not. For example, > recently I turned down a gig that was trying to use offloads to speed > up crypto processing of DNS packets, which historically, has never > been worthwhile, as the overhead of handing off the co-processor was > far far greater for small packets than doing it on the cpu was. The > real innovation for crypto processing was in adding better cpu > instructions. > > I also thought mu-mimo (one way broadcast to multiple stations) was a > total waste of time. I do have some hope for the more bi-directional > stuff in ofdma, but given the backoff structure of the wifi mac, and > the nature of tcp, mu-mimo introduced complexity for sub-zero benefit. > Merely firing all the people that marketed that and hiring on a few > more clued network developers instead, would have helped. > > OS developers also have needs and desires for useful stuff in hardware > that are sometimes bogus, and sometimes genuinely useful. In wifi, I > have longed for a tx or rx is almost done interrupt, being able to > directly dma from/to the kernel layout of a skb, a completion > interrupt and a dozen other things that i outlined in the presentation > above. As for bogus, someone added NAPI support to the ath10k when it > is totally unneeded at even the maximum interrrupt rate. No idea why > that happened. > > Lastly, hw or firmware that presents sane APIs to the overlying os > frequently does not happen due to lack of communication about what can > and should be done in software, > > > > I think the server market & structure & level of cloud innovation make > things different for ethernet NICs. > > > > Bob > > > > > > On Wed, Jan 10, 2024 at 3:23=E2=80=AFAM Toke H=C3=B8iland-J=C3=B8rgense= n > wrote: > >> > >> Bob McMahon writes: > >> > >> > This approach is not going to work. Sun workstations as the forwardi= ng > >> > planes for WiFi doesn't work nor scale and is cost & power > inefficient. The > >> > WiFi forwarding plane needs to be all hardware and not based off of > BSD. It > >> > has to be like a port asic in an ethernet switch. No SoC. > >> > > >> > Ethernet NICs are targeting servers where the workstation/NIC model > does > >> > work. WiFi is never going to be the basis for cloud servers. > >> > >> Well, the original context of the question was "Linux WiFi drivers are > >> terrible, what can we do about that", and, well, providing proper > >> upstream drivers at HW launch is the way to solve that. > >> > >> And even so, every Linux-based CPE in existence is a contradiction of > >> you assertion that software-based WiFi forwarding is "not going to > >> work". On the contrary, the SOCs with proper open source drivers and > >> support are the ones that work the best, because that means we can run > >> OpenWrt on them instead of the vendor crapware that they ship with. > >> > >> -Toke > > > > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. > > > > -- > 40 years of net history, a couple songs: > https://www.youtube.com/watch?v=3DD9RGX6QFm5E > Dave T=C3=A4ht CSO, LibreQos > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --0000000000009d29f3060eaee415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I perceive a few major issues per this analysis:
    <= li>This is still a sun workstation model - ditch the SoC, BSD & things = like DMAs and see what comes out on the other=C2=A0side. Build a switch and= /or transceivers
  • 802.11 standards set the road maps which is much a= bout spectrum=C2=A0efficiency so that's the direction
  • Open-sour= ce sw engineers have zero=C2=A0visibility=C2=A0into hw engineering actuals = so are woefully out of date (though it's understandable because the way= things=C2=A0are structured doesn't expose the state of engineering in = a public manner)
  • I think we need an e2e low-latency technical offer= ing. Not sure why there has been so much misinformation around this but it = hasn't seemed to help
Bob

On Thu, Jan 11, 2024, 1:31 AM Dave Taht <dave.taht@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">i so wish more of what I d= iscussed 8 years ago, had made it to the
chipmakers. Minstrel-blues, in the end, didn't work out, but seemed so<= br> promising (coupled rate and power control).
https://www.youtube.com/watch?= v=3DRb-UnHDw02o&t=3D1041s

On Wed, Jan 10, 2024 at 1:23=E2=80=AFPM Bob McMahon <bob.mcmahon@b= roadcom.com> wrote:
>
> > Well, the original context of the question was "Linux WiFi d= rivers are
> > terrible, what can we do about that", and, well, providing p= roper
> > upstream drivers at HW launch is the way to solve that.
>
> This is out of the scope of chip makers for modern chips. The os drive= rs are written by system integrators - specialization has divided these tas= ks. Chip makers don't affect open vs closed source drivers of systems.= =C2=A0 Think of a WiFi chip now as transistors with a small microcontroller= and not a linux NIC.

Mediatek has had an "Upstream first" wifi chipset development pol= icy
for many years now, the mt76 got competetive and the mt79 is looking
really good. It has a very minimal blob attached to it, and a decent
API (with a couple exceptions).

The offloaded cpu in the ath10k was actually quite powerful, and had
that code been more commonly available, it would not have taken so
many years and a mere *one* guy licensed to work on it, to get the
ath10k firmware up to snuff.

https://forum.openwrt.org/t= /aql-and-the-ath10k-is-lovely/59002

The R/T OS on that "microcontroller" was a nightmare of spaghetti=
written by EEs on crack.

I quiver in fear about even less open firmware blobs than that.
>
> One can argue that chip makers don't provide documents to open-sou= rce developers, which is mostly accurate. But documents aren't the bloc= ker.

Oh, they are key to understanding what the chip can be made to do
outside of the scope of the original designers.

> I think an open source community would have to innovate to a level to = drive the use of chips coming off a foundry line for a chip maker to consid= er assigning resources to support open-source teams. Old chips with 10+ yea= r old NRE doesn't justify any investment by anyone.

I would merely like a competent OS developer to be present from day
one of a new or being revised design to provide useful feedback from
the field about what ideas are BS and which are not. For example,
recently I turned down a gig that was trying to use offloads to speed
up crypto processing of DNS packets, which historically, has never
been worthwhile, as the overhead of handing off the co-processor was
far far greater for small packets than doing it on the cpu was. The
real innovation for crypto processing was in adding better cpu
instructions.

I also thought mu-mimo (one way broadcast to multiple stations) was a
total waste of time. I do have some hope for the more bi-directional
stuff in ofdma, but given the backoff structure of the wifi mac, and
the nature of tcp, mu-mimo introduced complexity for sub-zero benefit.
Merely firing all the people that marketed that and hiring on a few
more clued network developers instead, would have helped.

OS developers also have needs and desires for useful stuff in hardware
that are sometimes bogus, and sometimes genuinely useful. In wifi, I
have longed for a tx or rx is almost done interrupt, being able to
directly dma from/to the kernel layout of a skb, a completion
interrupt and a dozen other things that i outlined in the presentation
above. As for bogus, someone added NAPI support to the ath10k when it
is totally unneeded at even the maximum interrrupt rate. No idea why
that happened.

Lastly, hw or firmware that presents sane APIs to the overlying os
frequently does not happen due to lack of communication about what can
and should be done in software,
>
> I think the server market & structure & level of cloud innovat= ion make things different for ethernet NICs.
>
> Bob
>
>
> On Wed, Jan 10, 2024 at 3:23=E2=80=AFAM Toke H=C3=B8iland-J=C3=B8rgens= en <toke@toke.dk> wrote:
>>
>> Bob McMahon <bob.mcmahon@broadcom.com> writes:
>>
>> > This approach is not going to work. Sun workstations as the f= orwarding
>> > planes for WiFi doesn't work nor scale and is cost & = power inefficient. The
>> > WiFi forwarding plane needs to be all hardware and not based = off of BSD. It
>> > has to be like a port asic in an ethernet switch. No SoC.
>> >
>> > Ethernet NICs are targeting servers where the workstation/NIC= model does
>> > work. WiFi is never going to be the basis for cloud servers.<= br> >>
>> Well, the original context of the question was "Linux WiFi dr= ivers are
>> terrible, what can we do about that", and, well, providing pr= oper
>> upstream drivers at HW launch is the way to solve that.
>>
>> And even so, every Linux-based CPE in existence is a contradiction= of
>> you assertion that software-based WiFi forwarding is "not goi= ng to
>> work". On the contrary, the SOCs with proper open source driv= ers and
>> support are the ones that work the best, because that means we can= run
>> OpenWrt on them instead of the vendor crapware that they ship with= .
>>
>> -Toke
>
>
> This electronic communication and the information and any files transm= itted with it, or attached to it, are confidential and are intended solely = for the use of the individual or entity to whom it is addressed and may con= tain information that is confidential, legally privileged, protected by pri= vacy laws, or otherwise restricted from disclosure to anyone else. If you a= re not the intended recipient or the person responsible for delivering the = e-mail to the intended recipient, you are hereby notified that any use, cop= ying, distributing, dissemination, forwarding, printing, or copying of this= e-mail is strictly prohibited. If you received this e-mail in error, pleas= e return the e-mail to the sender, delete it from your computer, and destro= y any printed copy of it.



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=3DD9RGX6QFm5= E
Dave T=C3=A4ht CSO, LibreQos

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --0000000000009d29f3060eaee415-- --000000000000a4defe060eaee4c8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQagYJKoZIhvcNAQcCoIIQWzCCEFcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3BMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBUkwggQxoAMCAQICDDGs4Qlq5OZK9mcDzTANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAxMzMzNDFaFw0yNTA5MTAxMzMzNDFaMIGM MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFDASBgNVBAMTC0JvYiBNY01haG9uMScwJQYJKoZIhvcNAQkB Fhhib2IubWNtYWhvbkBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBfX3nsBFRdO26im8lhOadVadRmV/YWK+U9OoGlTE+2MDsjJwO5p/Q6iaTUropqMRH1E+EIuhe /OU6a3/btrqzARE77RaVSdz5swXt7M4ciN+z44nIEx36UQIlFLsBFa3is/J/QLFhTUFFf0wLJsUO wyja+KvygH/E5TyfeXf5T2Y2wjGZx8jQXZMDmNpfANlEBYDfzCNYcAIQNox8FuPpEpuxWvv7jvxV X5dfkSef9T/DbsDM0PeTVMVyYIQoRSMBIGxVkaqp0MJglvQ2mU4CXcoOGgm6XC8LoLoEvYojXFKC fRgCOT5xeMR10UPSBQIljKwt7fPhpYVY+jTtOclpAgMBAAGjggHZMIIB1TAOBgNVHQ8BAf8EBAMC BaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYBBQUHMAGG NWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwME0G A1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCMGA1UdEQQc MBqBGGJvYi5tY21haG9uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSME GDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUpG/4RP1YQA/iXGens9pIRe7CQxMw DQYJKoZIhvcNAQELBQADggEBACfWLy4qJyCnOa3sl4LEDAMU/gmJ6LbclGE5iR4KanAmlAt92gzN 5lSy/iE+wsRrXiHI7YKFgXX1kVK/RqMiPRrw4hq2j8nxoSi/VFiyS3CsfVMGkbY7HBTlBvla/tH+ +2nJprlXbJyz1GdvoJAeam5RvTWotcCGAjZmMa3U3zMkszgXN849xe3dUK1DauUGiInXEwEdXDcA /0CVjL3EEMj+kNWcLhrSZKwFtxggUyMW3XWRaAeAL9wOtEaXYqlgbtnV0n9FuoV2TNm3h7Mh7rjV I2zM+IZ3DE+XFK7dcPwte33u75QyySNJ3UMZqi25CO85yl8Bmo7aWRm99N7HGnkxggJtMIICaQIB ATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgwxrOEJauTmSvZnA80wDQYJ YIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIBnWlKXELS66koNvf3NdE/7fjbX9glxscCo+ wWkn6BRJMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTI0MDExMTE3 Mjk0M1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQCATAN BgkqhkiG9w0BAQEFAASCAQCmLCdH+pqdYis0/zcDZes3lpWsAuXbtpRXgruZIM1m6389WNwTZtIq z1FEc8/qk0K8JpKx0ZX++BxUjQo8XX5Ueq3F52/Zr7+gs6rFKqw9uS3J0oc8YYtIxjqIOUNDr1hA BeHnRikXQsSioNZ+Wa0awDQAhs1f+mLHAyTxzxzxqD9LKDna4AGhQdx1nG9aU8hc/XYNhWUNFbA3 s//M112D5LxERTJBtG5aIrq6MBmPQvNv9yN/ULrRbJveqIb33wHeqX2zmP/DXlLPd2mqmFsr5tOU ayk+SJyF5mRkibf0CjAJHAROF1BmUuN1lFb0OppyzK+A8VAymq1Jd5cgPPRS --000000000000a4defe060eaee4c8--