►
From YouTube: Hybrid Cloud Bursting Electronic Design Analysis Optical Proximity C.... Derren Dunn, & Gaurav Singh
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Hybrid Cloud Bursting Electronic Design Analysis Optical Proximity Correction (OPC) Flows to Public Cloud Managed Kubernetes Services - Derren Dunn, IBM & Gaurav Singh, Red Hat
Everyone is aware of the adage, “time is money”. No industry is more aware of this than the semiconductor industry in which time to market delays can cost billions of dollars. To do anything in this business, one must do 3 things: 1) design chips, 2) transfer design shapes to a photolithography mask, and 3) fabricate designs. In this talk, we will explore the transfer of design shapes to masks using OPC. OPC is an embarrassingly parallel high performance computing workload that is typically run on Linux clusters. Historically, semiconductor manufacturers have finite on-prem compute resources. To address compute limitations, we discuss methods to enable OPC hybrid cloud bursting using managed Kubernetes services. We present scaling OPC workloads from 1,000 pods to 10,000+ pods using managed Kubernetes services. Also, we explore benefits of using managed Kubernetes services in terms of performance, set-up, and the use of autoscalers to control costs at the job level.
11:20am – 11:30am L
A
A
So
give
you
a
view
of
what
I'm
hearing
from
my
customers
regarding
batch
and
and
this
type
of
activities,
so
I've
talked
to
a
lot
of
customers.
These
are
predominant
customer
who
comes
to
me
around
bash
type
of
Niche
right.
So
we
talked
to
life
science
customer
they
they
say
we
want
to
run
genome
simulations.
We
talk
to
manufacturing
customers,
they
want
to
do
computational
food
Dynamics.
A
A
So
when
I
hear
all
these
customer,
everything
boils
on
into
three
characteristics:
they
come
and
repeat.
You
know
the
characters
of
the
batch
workload.
They're
looking
for
one
is
asynchronous
run.
What
they
say
is
we
have
this
jobs?
The
jobs
needs
to
run
asynchronously
and
complete.
To
give
me
the
result,
these
jobs
are
computational.
Heavy,
you
know,
require
gpus,
fast,
nectares,
fast,
Network,
fast
storage,
and
these
are
massive
scale
and
since
they're
running
on
cloud,
they
need
some
type
of
elasticity.
A
So
listening
to
those
customers,
we
are
trying
to
address
few
few
problems,
either
from
red
hat
or
openshift
side
or
from
Community
side.
One
is
job.
Q
is
I,
think
the
font
is
very
small,
but
I'll
talk
through
it.
So
what
what
I've
seen
is
what
customer
is
asking
is
hey.
These
are
my
jobs,
put
it
in
a
cube
so
before
it
goes
as
scheduled,
and
that
queue
needs
to
be
dynamic
in
the
sense
that
the
first
job
does
not
mean
that
it
needs
to
execute.
A
First
I
should
able
to
prioritize
things
in
the
cube
so
that
you
know
I'm
I
want
to
make
sure
my
higher
priority.
Job
is
running
all
the
time.
I
think
Community
is
working
on
something
called
Q.
We
have.
We
internally.
Openshift
is
working
on
something
called
mcad,
which
is
basically
a
app
wrapper
and
dispatcher
for
queuing.
A
Then
a
dynamic
infrastructure
right.
So
we
talked
about
Q
when
a
job
comes
into
the
queue.
What
customer
wants
is
a
cluster
is
Spinner
for
them
right
these.
These
are
very
expensive
infrastructure.
They
do
not
want
it
to
spin
beforehand,
like
think
about
GPU
nodes,
and
all
these
are
expensive,
so
they
want.
Whenever
a
job
comes
in
the
queue
they
want
an
infrastructure
to
be
spent
and
when
there's
no
job
just
deprovision
the
whole
infrastructure,
so
that
you
know
you
do,
there's
no
cost
incurred.
A
Third
thing
is
the
gang
scheduling,
so
what
what
customer
says
is?
Let's
say:
I
have
10
jobs
and
infrastructure
has
capacity
for
five
to
run
five
jobs
make
sure
the
jobs
weighs
a
weight
until
all
the
resources
are
available
in
within
the
infrastructure,
so
all
kind
of
All
or
Nothing
run
all
jobs
or
nothing
in
the
gang
fashion.
A
These
other
trends
that
I'm,
seeing
by
talking
to
all
these
customers
so
I
mean
all
these
customer
use
cloud
in
one
way
of
form
for
their
application.
Now
they
see
benefit
of
it.
They
want
to
use
the
same
benefit
for
their
AI
ML
and
HPC
application,
multi-hardware
architecture.
So
what
I've
seen
is
what
customers
saying
is
hey
to
save
the
cost.
I
would
be
able
to
run
my
run,
my
management
on
the
arm
architecture
and
compute
on
x86
right.
A
So
you
need
to
have
multiple
multi
architecture
in
there
accelerators
we
talk
about,
they
want
to
use
GPU
smart
connects
fast,
Network
everything
that
clouds
present
today.
They
want
to
leverage
that
into
their
into
their
workload
containers
these
now
I'm
seeing
a
shift
where
customers-
you
know
old,
HPC
type
of
customer
running
on
HPC
workload,
on-prem
on
a
bare
metal.
They
are
transitioning,
mostly
re-hosting
and
looking
forward
to
re-platforming
their
HPC
type
of
workload
into
the
containers.
B
B
So
everybody
understands
I
will
also
go
into
a
little
bit
of
detail
about
why
we
want
to
do
Cloud
burst
it's
a
very
similar
story
to
what
everybody
else
wants
to
do,
and
some
of
the
benefits
for
us,
particularly
in
semiconductor
research
and
design,
for
doing
so
and
then
I'll
go
over.
Some
scaling
results
from
our
Optical
proximity
correction
workload
using
service
in
the
iCloud,
so
semiconductor
research
and
development.
My
role
is
to
span
Two,
Worlds,
I,
span,
process,
development
and
research.
B
I
also
span
hybrid
cloud,
and
my
sole
role
is
to
bring
these
two
worlds
together,
so
that
we
can
be
more
efficient
and
leverage
more
opportunities.
So
when
you
think
about
doing
semiconductor,
research
and
design,
you
could
boil
it
down
to
three
main
things.
You
need
to
be
able
to
design
new
circuits
and
chips.
You
need
to
be
able
to
transfer
what
you've
designed
to
photo
lithography
masks,
there's
no
way
you
can
do
anything
without
being
able
to
transfer
a
design
to
wafer
with
lithography
and
other
processing
processes.
B
So
the
tool
set
that
I'm
going
to
talk
about
today.
We,
we
use
multiple
tools
today,
specifically
I'm,
going
to
talk
about
a
tool
called
caliber
which
is
made
by
Siemens.
These
are
commercial
tools.
Typically,
an
engineering
design,
automation,
workflows
most
of
the
primary
tool
sets
are
commercial,
so
one
of
the
challenges
that
you
have
it's
taking
a
commercial
tool
that
has
been
written
for
a
more
typical
HPC,
Linux
cluster
environment,
containerizing
it
and
then
finding
efficient
ways
to
run
it
with
orchestrated
containers
on
openshift
or
bear
more
vanilla,
kubernetes
services.
B
So
when
we
talk
about
this,
what
we're
really
going
to
be
talking
about
is
taking
this
application.
This
application
is
meant
to
manage
the
transfer
through
the
photolithography
mask
from
euv
light
or
1938
to
an
actual
wafer.
When
you
break
this
process
down,
actually
it
it,
it's
a
consists
of
many
different
tool
flows.
When
we
finish
with
design
what
ends
up
happening,
is
we
get
a
database
file
format,
either
gds2
or
Oasis?
B
That
file
format
contains
a
representation
of
of
design
shapes
that
may
contain
upwards
of
10
billion
design
shapes
in
a
particular
layer
that
we're
going
to
transfer
as
part
of
the
process
of
figuring
out
ahead
of
time,
how
we
can
take
a
design
and
print
it
on
wafer.
We
have
to
go
through
several
steps.
One
of
them
is
called
design
for
manufacturing,
that's
actually
taking
the
ground
rules
that
were
established
for
the
technology
figuring
out.
What
actually
has
to
happen?
B
What's
printable,
what's
transferable
and
if
we
need
to
change
design
rules
go
ahead
and
do
that.
We
then
need
to
fill
use,
use
other
shapes
to
fill
the
gaps
in
a
design
without
impacting
the
performance
of
the
design
and
that's
a
tool
and
a
technology
all
to
itself.
In
many
cases,
what
we're
doing
is
we're
decomposing
a
design
into
multiple
colors
and
printing
a
color
at
the
same
time,
and
the
reason
for
that
is
is
that
as
we
get
beyond
the
three
nanometer
known
five
nanometer
node,
you
know
even
starting
a
10
nanometer.
B
We
can't
print
the
entire
design
with
a
single
color
or
a
single
exposure.
We
need
to
find
ways
to
break
it
apart,
so
that
we
can
actually
Pat
what
we
need
to
do.
And
then
we
talked
about
retargeting,
where
we
take
those
shapes,
we
change
them
slightly,
so
that
we
can
actually
print
them.
We
will
put
insert
features
through
code
called
sub-resolution,
assist
features.
Those
are
required
to
help
the
lithography.
B
Actually
print
particularly
intermediate
to
isolated
shapes,
and
then
we
finally
do
Optical
proximity
correction
and
we
also
verify
that
the
shape
that
we've
created
will
actually
print
on
wafer,
using
modeling
to
within
a
certain
tolerance
or
expected
a
variance.
So
in
a
nutshell,
what
is
Optical
proximity
correction?
B
You
can
think
about
this
as
an
optimization
problem
prior
to
about
the
90
nanometer
technology
node,
you
could
actually
take
a
drawn
shape,
multiply
it
by
a
scaling
factor
and
transfer
it
to
a
lithography
mask
and
you'd
have
a
pretty
good
probability
of
hitting
the
target
for
the
design
and
and
people
would
come
up
with
some
rules-based
changes,
but
typically
it
was
just
a
straight
shot,
starting
in
90
nanometer.
That
wasn't
true.
So
if
you
look
at
this
diagram
without
OPC,
that's
the
drawn
shape,
you
would
bring
it
you.
B
You
could
think
about
the
lithography
process
as
a
series
of
transforms
one
transform
is
to
transform
it
to
the
mass,
the
other
one
is
to
expose
it,
and
the
other
one
is
to
etch
it
on
wafer.
What
typically
happened
at
90,
nanometer
and
Beyond
is
the
shape
that
we
brought
in
as
the
design
shape
no
longer
was
represented
on
on
the
wafer.
In
fact,
in
some
cases
some
shapes
wouldn't
print
it
off.
B
So
there
was
a
technique
called
Optical
proximity
correction
that
was
developed
in
which
you
bring
in
the
design
shape
you
partition
it
into
vertices
and
edges.
You
then
expose
that
partition,
partition,
shape
or
calculate
what
the
aerial
image
would
be,
which
is
a
very
physical
process,
and
you
apply
a
an
empirical
resist
model
to
it
to
predict
what
the
shape
will
print
on
wafer
and
then
you
iterate
until
you
either
hit
a
fixed
number
of
iterations
or
a
cost
function
has
been
matched
and
you
then
output
that
onto
the
the
photolithography
mask.
B
So
you
end
up
with
a
lot
of
very
complex
serif
shapes
when
you
do
this,
so
how?
How
is
this
represented
from
a
compute
process?
So
this
is
actually
a
two-part
compute.
You
have
a
primary
path
process
that
reads
in
the
design:
layout
chops
it
up
into
tiles
and
creates
a
cue
or
a
heap
once
it's
done
with
that.
B
It
spins
up
a
bunch
of
remote
workers
on
a
on
a
traditional
Linux
cluster,
in
our
case
on
an
open,
shifter,
kubernetes
cluster,
and
then
it
starts
parsing
out
work
tile
by
tile
to
all
of
the
workers,
and
it
does
this
in
a
round
robin
fashion
until
the
work
until
all
of
the
tiles
in
the
queue
or
the
Heap
have
been
exhausted,
there's
no
need
for
the
remotes
or
the
worker
processes
to
communicate
with
one
another.
So
it's
a
very
traditional
Hub
and
spoke
process.
B
So
when
we,
when
we
talk
about
this
in
a
traditional
sense
and
and
bursting
to
the
cloud,
what
problem
are
we
trying
to
solve?
What
we're
really
trying
to
do
is
expand
our
opportunity
Horizons
to
work
on
more
and
more
projects.
You
can
think
about
this.
As
a
triangle,
we
have
three
main
resources
that
we're
trying
to
optimize.
One
of
them
is
compute,
one
of
them
are
commercial
licenses
for
the
tools
and
the
other
one
is
people.
B
Okay,
the
most
sticky
component
that
you
have
are
people,
it's
not
easy
to
expand
a
design
team
or
an
OPC
team
or
a
patterning
team
in
short
periods
of
time.
The
two
things
that
you
can
expand
are
compute
and
licenses.
So,
if
you
think
about
the
semiconductor
interest,
industry
as
a
whole,
there
are
more
opportunities
than
capacity
to
take
care
of,
but
and
and
time
to,
Market
is
huge
So,
the
faster
that
you
can
realize
an
opportunity,
the
more
opportunities
you
can
work
on.
B
So
people
spend
a
lot
of
time
trying
to
figure
out
how
do
I
maximize
my
opportunities.
There's
two
ways
that
that
you
could
do
this
and
one
is,
is
to
increase
your
compute.
The
other
one
is
to
increase
the
number
of
licenses
and
these
two
have
to
go
concurrently.
Okay,
so
if
we
have
a
smaller
opportunity,
Horizon
that's
referenced
in
the
in
the
yellow,
but
we've
got
a
lot
of
projects
that
we
really
want
to
explore.
What
are
the
best
ways
for
us
to
do?
B
B
So
if
you
could
come
up
with
a
way
that
that
people
are
submitting
jobs
to
a
compute
resource
and
you
can
expand
the
the
compute
license
and
people
triangle
to
maximize
your
opportunities
and
and
deliver
more
in
the
same
period
of
time,
so
our
Cloud
burst
strategy
from
the
beginning
is
to
use
OPC
or
Optical
proximity
correction
as
a
proxy
workload.
We
want
to
create
the
same
on-prem
infrastructure
as
we
as
we
would
use
in
the
cloud,
and
we
want
to
Target
managed
kubernetes
Services.
B
What
that
does
is
that
lets
us
minimize
the
amount
of
configuration
and
tweaking
that
we
do
when
we
burst
to
the
cloud
and
helps
us
realize
this
vision
of
sane
compute
on-premise
we
have
in
the
cloud.
We
also
want
to
centralize
license
servers
in
the
cloud
to
avoid
splitting
pools
or
having
gaps
in
time
from
when
we
can
leverage
the
cloud
or
not
and
also
develop
our
controllers
and
operators
to
make
public
Cloud
bursts
with
openshift
transparent
to
the
engineering
teams.
So
this
is
a
pictorial
diagram
of
the
type
of
infrastructure
that
we're
talking
about.
B
On
the
upper
left-hand
side,
we
have
our
on-prem
compute.
We
have
interactive
compute
to
set
up
jobs,
to
view
results
to
also
change,
do
job
management,
and
we
also
have
a
number
of
openshift
clusters
that
we
maintain
internally
with
shared
distributed
file
space.
When
we
burst
into
the
cloud
we
target
our
a
service
called
rocks,
which
is
Red,
Hat
openshift
kubernetes
service
in
the
IBM
Cloud.
You
know
if
you're
used
to
AWS,
you
might
think
of
this
as
Rosa
and
in
the
cloud.
B
What
we
do
is
we
build
some
some
compute
nodes
and
job
management
nodes,
and
we
want
to
run
across
as
many
data
centers
in
a
cloud
burst:
geography
as
we
can,
so
we
can
maximize
our
capacity
leverage,
Auto
scalers,
where
we
can
so
we
can
scale
up
and
scale
down
to
save
costs
and
centralize
the
license
managers
in
in
a
cloud,
geography,
that's
accessible
to
all.
One
of
the
key
things
that
you
you
could
do
in
almost
any
cloud
is
connect
different
regions
via
networking
that
exists
solely
in
the
cloud
itself.
B
B
So
how
does?
How
does
our
workflow
work,
based
on
the
description
I
gave
you
earlier?
How
do
we
set
this
up
in
kubernetes
and
I'm?
Sure
people
here
could
come
up
with
many
different
ways
to
do
this.
We
chose
because
of
the
nature
of
these
tools,
to
try
to
mimic
as
much
as
we
possibly
could
the
way
that
these
jobs
run
on
a
native
Linux,
bare
metal,
Linux
cluster
and
the
reason
why
we
wanted
to
do
this
was
twofold
one.
B
It
solves
a
problem
of
OPC
Engineers
or
design
Engineers
understanding
how
their
jobs
are
running
and
two
with
very
you
know,
small
tweaks
to
a
to
a
controller
or
an
operator
in
kubernetes.
We
can
build
in
resilience
to
this
workload
by
making
sure
that
we
leverage
inherent
capabilities
and
kubernetes
to
keep
worker
nodes,
for
instance
up
if
they
go
down,
make
sure
that
we
can
checkpoint
and
and
start
and
and
restart
jobs,
scale
them
down
so
that
we
can
prioritize
jobs.
So
what
happens?
Is
we
use
kubernetes
job
types?
We
have
two.
B
We
have
a
primary
job
type
which
it
starts
initially.
What
it
does
is
exactly
what
I
talked
about
before
it
reads
in
the
layout
chops
it
up
into
tiles
and
creates
a
queue
once
it's
done.
It
then
talks
to
a
distributed
controller
that
then
spins
up
a
number
of
workers
and
when
I
talk
about
workers,
in
this
case,
we're
talking
about
running
at
fairly
large
scale,
table
Stakes
for
an
OPC
run
is
typically
between
8
000
pods
and
sixteen
thousand
pods.
B
B
Let's
go
out
figure
out
how
to
assemble
job
flows
like
this
and
demonstrate
scaling
from
a
thousand
to
ten
thousand
pods.
If
we
could
do
that
in
a
fairly
linear
fashion,
then
we
have
confidence.
Then
we
can
go
and
do
this
at
more
scale.
One
of
the
other
reasons
for
breaking
this
apart
are
breaking
our
job
flows
apart
is
it
also
lets
us
address
the
differences
between
running,
let's
say,
four:
twenty
five
hundred
pod
runs
and
one
ten
thousand
pod
run
on
the
same
cluster
and
also
lets
us
address.
B
Some
of
the
shared
file
system
issues
that
we
have
so
one
of
the
things
to
keep
in
mind
is
for
for
many
of
these
tools
and
many
HPC
workloads.
A
shared
high
performance
file
system
is
really
key.
All
of
the
worker
pods
need
to
see
the
same
file
system
read
and
write
to
it
and
Stat
it
that
the
primary
pod
sees
and
they're
going
to
do
this
on
with
irregular
patterns.
B
So
one
of
the
ways
that
we've
made
this
made
our
work
happen
here
is
to
explore
both
open
source,
high
performance
file
systems
like
SEF
or
or
internal
file
systems
like
gpfs
or
Spectrum
scale,
and
we,
what
we
tend
to
do
is
offer
Seth,
gluster
or
gpfs
as
persistent
volume
claims
that
are
mounted
by
all
of
the
pods
in
in
the
run,
and
we
keep
those
static
and
there's
also
another
advantage
to
that
is
when
we
have
to
go
back
and
debug
logs.
Everybody
can
see
the
same
thing.
B
B
So
you
know
one
of
the
things
that
that
I
get
asked.
I
I
get
some
skeptical
questions
up
front
with
new
OPC
engineers
and
new
designers
is
yeah.
This
is
all
great,
it
looks
convenient,
but
is
it
going
to
perform?
How
do
I
know
that
if
I,
just
you
know,
give
you
a
kubernetes
job,
then
I'm
going
to
get
it
in
the
time
that
I
need
to
do
it
so
over
the
last
two
years
or
so
we've
been
we've
been
looking
at
scaling
and
OPC
is,
is
embarrassingly
parallel.
B
It
should
scale
fairly
linearly,
but
there
are
parts
of
the
job
that
need
to
do.
I
o
need
to
do
some
checking
in
in
the
hierarchy
management
the
primary
pod,
so
we
don't
expect
it
to
to
be
pure
linear.
So
what
I've
done
here
in
this
in
these
results
is
plot.
A
couple
of
things:
I
plotted
the
speed
up
that
you
would
expect
if
everything
was
linear,
which
is
really
just
this
line.
The
black
line
that
you
see
here
the
next
thing
that
we've
added
is
a
speed
up.
B
Assuming
you
have
a
Serial
fraction
of
about
15,
that's
something
more
attainable
than
pure
linear.
Given
the
amount
of
file
and
networking,
I
o
that
we
need
to
do
and
then
what
I
did
was
plot.
Our
speed
up
in
the
blue
curve
for
OPC
runs
that
span
a
thousand
pods
to
ten
thousand
pods
for
our
Nano
sheet,
node,
which
you
can
think
of
as
three
nanometers
to
two
nanometers,
depending
on
who
you
talk
about
or
talk
to
for
a
a
back
end,
wiring
level
back
in
wiring
levels
and
I.
B
Apologize
for
using
jargon
are,
are
the
is
the
first
wiring
level,
that's
most
important
for
signals,
and,
and
you
know
that
they're
called
The
Thin
wire
levels
and
there's
a
couple
of
them,
but
the
first
one
is
the
most
important.
So
what
we're
showing
here
is
that,
with
in
the
blue
curve
scaling
from
one
thousand
to
ten
thousand
pods
we're
achieving
a
pretty
close
correlation
with
about
a
15
I
o
or
serial
fraction,
which
is
actually
quite
good
where
by
no
means
done
with
this.
B
So
to
summarize,
we
we've
successfully
demonstrated
running
Optical
proximity
correction
at
scale
using
a
managed
openshift
service.
We
are
targeting
management,
managed,
openshift
Services,
because
it
minimizes
setup
and
tear
down
in
public
Cloud
infrastructure
and
we're
applying
what
we've
learned
using
optical
proximity
correction
to
many
other
tools
in
the
design
change
this
design
tool
chain.
So
we
can
apply
this
to
the
tools
that
we're
actually
using
to
do
register,
transistor
logic,
synthesis
place
in
route,
timing
and
enclosure
and
performance.
B
We've
got
a
lot
of
opportunities
to
build
logic
and
custom
controllers
into
this
flow
I.
You
know
we
view
this
as
as
the
first
step
we
do
use
for
all
of
our
Mass
delivery
into
Albany
nanotech
today,
openshift
and
and
a
managed
kubernetes
service,
so
we're
in
in
a
sense-
and
this
is
something
that
we
always
have
to
do
within
IBM.
Our
management
team
always
insists
that
we
eat
our
own
cooking.
So
we
can't
go
out
and
say:
hey
everybody
should
use
kubernetes
or
everybody
should
use
openshift.
B
We
actually
have
to
do
that
and
make
sure
that
it
works
for
us
and
that
we
could
stand
behind
it
and
say
yep.
Here's
the
data
I
can
scale
from
a
thousand
to
ten
thousand
pods
I
get
good
results.
I
can
do
this
reliably
and
I
think
what
this
is
also
going
to
do
is
enable
us
to
make
smarter
use
of
public
cloud
services,
the
IBM
cloud
in
particular,
but
also
not
to
limit
ourselves
to
that
we're
also
a
hybrid
Cloud
company.
B
C
B
Yet
we
we
would
like
to
we
started
very
simply
because
you
know
we
we
had
to
solve
some
problems
or
some
some
I
won't
say
problems.
We
had
to
optimize
our
containerization
flow
and
in
order
to
keep
things
simple
on
the
compute
side,
we
didn't,
we
didn't
try
to
do
anything
more
sophisticated.
That's
one
area
where
we'd
like
to
go
is
is
use
particularly
on
the
on
the
operator
side
and
the
scheduling
side
better
or
leverage
open,
open
source
projects
to
actually
do
that
better
within
within
openshift.
B
A
To
add
one
more
thing
so
also
things
like
crd
changes,
custom
configuration
on
the
Node
so
for
that
we
are
looking
at
Argo
CD
things
like
that
when,
whenever
you
have
job
coming
and
before
the
infrastructure
spin
up,
you
have
Argo
CD
comes
in
and
you
know
prep
the
infrastructure.
So
things
like
that
you're
looking
at
the
Argo
City
in
that
way,.
D
D
E
B
D
B
B
I
I
think
we
need
to
be
a
little
more
rigorous
about
Version
Control
and
how
we
Benchmark
different
versions.
We're
not
doing
that
today,
but
that's
one
of
the
things
that's
on
our
list,
but
I
have
seen
some
improvements,
definitely
from
three
to
four,
with
networking
and
and
our
file
system
performance
and
our
ability
to
tune
them.
The
compute
is
also
better
but
I.
You
know
it's
hard
for
me
to
quantify
it,
because
these
workloads
don't
make
very
good
use
of
hyper
threading.
B
A
Just
to
one
more
thing,
so
openshift
is
100
kubernetes.
We
are
also
making
Improvement
on
Upstream
as
well,
so
things
like
C,
then
c
groups
V2.
These
are
coming
going
forward,
which
will
enhance
the
other
performance.
I
mean
we
have
seen
better
results
in
in
the
lab,
and
we
are
going
forward
to
implement
this
within
openshift
as
well
so
going
forward.
You
will
see
good
I
mean
I
will
working
with
Darren
to
see
how
the
graph
looks
like
when
we
Implement
those.
B
They
are
so.
This
is
a
managed
service.
They
are
running
external,
we're
building
them
within
the
same
VPC,
but
the
control
plane
for
the
the
cluster
is
is
separate
and
it's
different.
So
when
we
do
the
mounts,
what
we
do
is
is
we're
provisioning
virtual
machine
nodes
in
the
VPC
and
the
control
plane
is
managing
all
the
connections.
So,
if
I
understand
your
your
question
as
being
external,
the
the
file
systems
are
in
the
same
are
in
one
of
the
data
centers
that
the
VPC
encapsulates
the
block.
B
F
B
Did
so,
and
it's
really
not
a
it's,
not
really
a
fair
comparison.
Seth
Seth
performs
much
better
than
almost
any
of
the
other
open
source
file
systems
that
that
we've
tried
thus
far-
and
you
know
truth
in
advertising.
We
haven't
tried
luster
yet,
but
you
know
between
gluster
Bayer
NFS
built
over
block
storage,
Seth
outperforms
them
all.
Gpfs
is
really
optimized
for
HPC
and
it
has
some
features
that
Seth
doesn't
have
which
allows
it
allows
us
to
tune
metadata
and
and
just
performance
in
much
more
finely
than
we
can
with
SEF.
B
E
B
So
in
some
sense
it's
it's
not
as
it's
not
a
true
Apples
to
Apples
comparison,
it's
more
if
I'm
willing
to
go
out
and
get
Spectrum
scale
take
the
time
to
configure
it
and-
and
there
are
managed
services
for
gpfs
today
or
Spectrum
scale,
but
like
any
anything
else,
you've
got
to
tune
in,
and
so
it
just
has
more
capability
under
the
hood
than
Seth
does
out
of
the
box
and
I
think
that's
the
main
way
to
explain
it.
It's
it
and,
and
it
it
it's
often
used
in
in
universities,
National,
Data,
Centers.
B
So
there's
there's
this
entire
body
of
work
where
people
have
figured
out
for
this
workload.
Here's
how
gpfs
gets
configured
so
so
it's
it
I
expect
it
to
outperform
Seth
out
of
the
box.
Now,
maybe
there's
somebody
who's
a
SEF
better
at
Seth
than
I
am
who
could
get
very
close
or
beat
gpfs,
but
you
know
gpfs
is
really
starting
with
a
you
know.
A
huge
Arsenal
ahead
of
time,
a
huge
priority
advantage.