platforms, regardless if you're doing shaping, AQM or none of them (FIFO).
If it's not hw accelerated, it sucks.
When I did tests on MT7621 it did ~100 meg/s without flow-offload, and
full gig with it.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
with flowoffload enabled, or is that not accelerated
on for instance MT76? I'm surprised since MT76 can barely do 100 meg/s of
large packets using only CPU?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https
a support ticket until 600ms or more.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
good, I like it! Thanks!
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
of throughput,
because it has a very slow CPU (but has plenty of offloads, so full gig
with offloads enabled works well, but then you don't get any SQM/DPI).
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
routing results in ~100 megabit/s of
throughput, whilst the HW offload engine is perfectly capable of full gig
speeds. MT7621 being one that actually is supported in OpenWrt.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat
1
bk_flows010
un_flows000
max_len 068130 3714
quantum 1514 1514 1514
--
Mikael Abrahamssonemail:
swm...@swm.pp.se___
with 2 x 2.5GbE NICs.
When using something like this for routing with HTB+CAKE for bidirectional
shaping below line rate, what would be the main things that would need to
be improved?
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing
1514 1514
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
4946683
way_inds 33
way_miss 969
way_cols0
drops 0
marks 0
ack_drop0
sp_flows2
bk_flows1
un_flows0
max_len 21196
quantum 1514
--
Mikael Abrahamsson
no
bufferbloat.
This is not perfect but it works well enough to make a big difference for
all normal use-cases.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
--- End Message ---
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https
flows?
That's extremely relevant, and I'd definitely like to simulate several UDP
50pps sessions with different DSCP values and see if there is any
difference between them, and indeed if bleaching etc is going on.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
nicely.
I also considered using WebRTC or VoIP libraries, does anyone know what
RTT/PDV/packet loss data can be extracted from some common ones?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https
On Tue, 3 Sep 2019, Kenneth Porter wrote:
I'm guessing there's no pretty Luci web admin thing for it. Pointers to
how to write one would be welcome. I'm sure others would love having GUI
knobs for it.
There is luci-app-sqm that I am using to configure sqm.
--
Mikael Abrahamssonemail
fw3 */
But you might be right that in places with a lot more clients then this
might indeed cause problems.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
... if anyone want to do
anything, that'd be nice.
What codebase does dslreports speedtest use, it seems to have a very nice
bufferbloat test?
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https
is set up.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
understand the problem with
bufferbloat to create market demand for the solutions available.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
the impression that basically all containers used network
namespaces to do whatever it is they do. All (most) the guides I have seen
on how to setup container networking seems to propose configuration setups
where namespaces are used.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
it was
uploaded to arXiv?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
way
to tell how old a paper is?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
of packets at
receive side?
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
?
Generally people in the IETF are acting as individuals, not
representatives of a company. If you put in "INTERNET!!!" as affiliation
I'm pretty sure nobody would care.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing
On Wed, 3 Apr 2019, Ryan Mounce wrote:
On Wed, 3 Apr 2019 at 00:04, Mikael Abrahamsson wrote:
What you described is probably on 95% or more of egress shaping on the BNG
and on egress shaping on HGWs in the field.
How many of these single queue deployments actually have ECN marking
enabled
blind cake for ingress shaping?
What you described is probably on 95% or more of egress shaping on the BNG
and on egress shaping on HGWs in the field.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
whatever. So
shaping is done egress on BNG and it tries to send at lower rate than any
of the L2 devices. Generally there is no ingress shaping of any kind on
the HGW, it doesn't even know what speed the subscription is.
--
Mikael Abrahamssonemail: swm.
common in the
future.
A lot of devices do not currently have the "mark ECN" as option in their
RED behaviour, but some do.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffe
On Tue, 26 Mar 2019, Holland, Jake wrote:
Hi Mikael,
Any operator nibbles on making this meeting happen?
Nobody else expressed any interest in this, so I kind of dropped the idea.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing
with FIFO yielded 100ms buffering just by naive
configuration, adding one line of random-detect config brought this down
to 10-15ms without any loss of actual throughput.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat
remaking is done
equally at the customer edge and peering/transit edge respectively.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Sat, 23 Mar 2019, Roland Bless wrote:
I suggest to use an additional DSCP to mark L4S packets.
DSCP doesn't work end-to-end on the Internet, so what you're suggesting
isn't a workable solution.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
On Thu, 21 Mar 2019, Mikael Abrahamsson wrote:
Btw, in
http://1ukcym66nom10cmylunctf84-wpengine.netdna-ssl.com/wp-content/uploads/2018/11/TR-156_Issue-2-1.pdf
5.2.x you can see how scheduling is done. If you'd like something like
that changed then anything new needs to go into documents like
On Thu, 21 Mar 2019, Mikael Abrahamsson wrote:
I might not agree with how these people decide networks should be built,
but that's unfortunately the way things look in a lot of cases. Telling
them to just do "FQ, how hard can it be?". Typically, the answer is
"hard, for a multi
ot;. Typically, the answer is "hard,
for a multitude of reasons".
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
time to cut TCP off and come up with something new, the bad
part is that it seems all innovation then has to be done over UDP which
has its own drawbacks (because of NATs).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloa
On Sun, 17 Mar 2019, Luca Muscariello wrote:
Fq_codel has an outstanding footprint in terms of deployment.
No, it doesn't.
A logical next step to me seems to push chipcos to build fq_codel in
silicon.
It is totally feasible.
... and how do you plan to make that happen?
--
Mikael
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
etting PIE or even RED, if it was just implemented.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
t it fits better into actual silicon and it's being proposed by
people who actually have better channels into the people setting hard
requirements.
I suggest you consider joining them instead of opposing them.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
On Mon, 11 Mar 2019, Jonathan Morton wrote:
On 11 Mar, 2019, at 11:07 am, Mikael Abrahamsson wrote:
Well, I am not convinced blowing the last codepoint on SCE has enough merit.
I will make a stronger statement: I am convinced that blowing the last
codepoint on L4S does *not* have enough
On Mon, 11 Mar 2019, Jonathan Morton wrote:
Seriously? I had to dig in the specs to find any mention of that, and…
it's all about better supporting bonded links. Which can already be
It doesn't stop there. Right now DOCSIS, 3GPP networks, Wifi etc all do
ordering guarantees, so they will
ation just to preserve
ordering within the 5 tuple stream.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ng this last unicorn codepoint. I'd like its use to be truly novel
and be more than a tweak.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
/PCQIrEs7/benefits-of-ack-filtering
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
basically have to do with normal L4
protocols that end customers typically use.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
my 20 year networking career where it's not
and applications misbehaved when they were re-ordered.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
going forward?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
that case.
FQ is a fringe in real life (speaking as a packet moving monkey). It's
just on this mailing list that it's the norm.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffe
ess though, and I think
https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-06 is one step in the
right direction. Just the fact that we might have two queues instead of
one in the simplest implementations might help. The first step is to get
ISPs to not bleach diffserv but at least allow 000xxx.
and bufferbloat).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
that L4S doesn't do but might do with
minor modification, it might be better to join him than to fight him.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
ready handles this
(at least per-stream).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
at because to me a
router is a router.
I do not do coax. I do not do PON. I do point to point ethernet using
routers and switches, like god^WIEEE intended.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
.
If you just cut the buffer down to 10ms and do nothing else, the only thing
you get is a short queue and may throw away half of your link capacity.
If i have lots of queue I might instead get customer complaints about high
latency for their interactive applications.
--
Mikael Abrahamssonemail
commenting on your
specific text directly, my question was more generic.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
e link to 100% and sometimes failing and inducing delay instead.
Could someone perhaps comment on the thinking in the transport protocol
design "crowd" when it comes to this?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
B
ow-buffer, fixed configuration ones.
Above is principle, there are of course combinations and optimizations to
be made so not all devices adhere exactly to the above.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Blo
everything in CPU.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
site using an OSX app they ship.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
.63 #0 SMP Wed Aug 15 20:42:39 2018 armv7l GNU/Linux
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
hese tests are done when rest of people in the household was also using
Internet for other things, so not "clean room".
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
829588333230
way_inds 12061686
way_miss 12913211
way_cols1
drops 11811
marks3589
ack_drop0
sp_flows1
bk_flows1
un_flows0
max_len 38444
quantum 1514
--
Mikael Abrahamssonemail
).
https://imgur.com/a/96dFdho
Thanks everybody for the excellent packaging and ease of use for end users
to get this to work. I've had this running now for 40 days without any
issue.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing
they received
fq_codel for free when the Linux kernel got support for it? They just had
to make it configurable?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
availability of the service.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
PIE.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
interface.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
her people working on Marvell drivers as well.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
: that's for GPON SFP ONTs.
Just the SFP, right?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
currently working on XDP-enabling the drivers for that
board (Marvell 8040).
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
Broadcom HGW and power usage went up from 9.4W to 10.2W. So if
it's a GPON or similar then I'd imagine it's substantially more
considering that it's quite a lot more things a GPON device needs to do.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
en doing this though, so we don't make that bad
again.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
reason it's still being new installed is because it's cheap.
In most of the world, customers do not rent the CPE so there is no cash
flow to the ISP to fix anything. So they tend to sit there until they
break.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
. It helps on lower end CPU
platforms (I've tried it there too), but not for the 10GE forwarding case.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
so the
kernel never sees the packets after initial flow setup.
So you need to get the people developing that silicon to get with the
program.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https
freeing up more CPU that isn't used for anything anyway.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
QCBE 1h44m in (proposed IEEE
802.1Qcz work) is the one I am thinking of.
Wonder how this would interact with the timing wheel proposed by Van
Jacobson?
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
would be awsome. I am great fan of PLPMTU and this should be
default-on everywhere in all protocols.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
new protocol, but I imagine this
is not a hard thing to do. I still have hopes for the flow label in IPv6
to do this job, even though it hasn't seen wide adoption so far.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat
appreciate this.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
.
However, the IETF should not do POSIX APIs, but instead something of their
own.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
that area.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
all major operating
systems.
This is not ideal, but it's not strange that this is happening. The only
way to innovate as an application/protocol developer is to use UDP.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@l
On Mon, 12 Feb 2018, Dave Taht wrote:
but to me the simpler thing would be to garner folk to ask at
vendor/isp press conferences: "Have you implemented RFC8290 yet? If
not, when?"
Has anyone implemented FQ_CODEL in a packet accelerator, or is this still
a CPU thing only?
al minutes, but can't
come up with an explanation to this behaviour, at least not from the
typical kind of DDOS that's going around. If there was some kind of ddos
mitigration equipment put into the mix, that might explain what you were
seeing.
--
Mikael Abrahams
r hops (if one wants any kind of
high bitrate).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
o handle
events that increase traffic temporarily, plus handle loss of capacity in
case of a link fault). The upgrade might be to add another link, or a
higher tier speed interface, bringing down the utilization to typically
half or quarter of what you had before.
--
Mikael Abrahams
network is never full for any
sustained amount of time, in normal operation, and make sure you perform
upgrades well before the growth has resulted in network being full.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Blo
downstream, meaning less
capacity overall. Symmetric access capacity costs real money and results
in less overall capacity unless it's on point to point fiber.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat
he problem if I
don't have enough throughput available to me that I need for my
application.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
).
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
s of power and DSPs to figure out what's
going on.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
not the biggest problem. My in-house cabling can do 10GE,
but I guess I'm an outlier.
--
Mikael Abrahamssonemail: swm...@swm.pp.se___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
pay 2x my current MRC to get 1000/100. However, if I had to downgrade
to 30 megabit/s I would most certinaly notice it, and in my market that
would just be a 20-30% saving which definitely isn't worth it.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
ng 16 sequential ACKs
here in my buffer, sitting waiting to get sent, is just useless
information. Let's kill the 15 first ones."
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buffe
er.
I am in complete agreement with you that any scheme that relies on
Internet-wide QoS scheme based on diffserv/TOS is a no-go. No ISP will
listen to this and act on it, as it's a DoS vector.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
___
Bloat ma
etwork worth anything should be able to smooth out "bursts" of 16-64
kilobytes at line rate anyway, in case of egress and the line rate there
is lower than the sending end is transmitting packets at.
--
Mikael Abrahamssonemail: swm...@swm.pp.se
middleboxes doing things.
I wanted to understand why TCP implementations find it necessary to send
one ACK per 2xMSS at really high PPS. Especially when NIC offloads and
middleboxes frequently strip out this information anyway so it never
reaches the IP stack (right?).
--
Mikael Abrahamsson
1 - 100 of 184 matches
Mail list logo
