MySQL | Learning as a beginner | Day one

Profiling MySQL Queries with phpMyAdmin

Here is the article. 

John CoxLast updated Jul 1, 2010

 Read Time: 19 min                Deutsch               English           

I have used phpMyAdmin for over a decade. In my early years with the tool, I simply needed something that could show me table structure and quickly give me the data inside. As my needs have grown, so have the tools included with phpMyAdmin which keeps me coming back as my primary MySQL tool, even with optimization.

Introduction and Scope: Using the Tools at Hand

I have had the pleasure to work with several different databases. Each have their drawbacks, and each have their strengths. When given a choice, I tend to migrate back to MySQL, despite me being too cheap to purchase the MySQL Enterprise. Instead, I make due with phpMyAdmin as my main profiling tool. It works well for me, but I had to do quite a bit of research to understand what I am looking at while profiling my applications. I am hoping to pass this along in a way that can be understood by the beginner, up to the seasoned pro.

Optimization takes time. Managers, clients, and peers for that matter, do not like to hear that a project is behind schedule because of optimization. Often times we rush the optimization in order to meet those benchmarks. In the end though, we aren't doing anyone any favors. The prettiest web application in the world is going to get you repeat business if it takes 10 seconds to load every page. Likewise, if we wait to optimize until the end of our projects, chances are there will be much more work to do, than if we had been checking as the project goes along.

A couple of notes before we get into the meat and potatoes. First, I am not going to get into MySQL Tuning, as it is a bit out of the scope for this tutorial. While tuning is optimization, it's a topic all to itself in my opinion. I will briefly mention a couple of opportunities to optimized how to tune your server, but the mentions will be brief. In addition, I will be mainly looking at MyISAM tables and not InnoDB tables. The rule of thumb is if you are writing lots of data, use InnoDB, but if you are using SELECT much more, then use MyISAM. Also, I am not getting into table level REPAIR, OPTIMIZE, CHECK and ANALYZE as this tutorial is covering query optimization with phpMyAdmin. Again, this is a bit out of the scope for this tutorial.

Finally, I am going to look at WordPress as a real world example. I will be the first to tell you that I am not an expert in WordPress, but I can look at the generated queries with the best of them. From what I have seen the database with WordPress is well indexed, but once we start adding things that are outside of those main core files, those indexes might not be the best for what we need.

"Optimization takes time. Managers, clients, and peers for that matter, do not like to hear that a project is behind schedule because of optimization."

 

Do I Need to Optimize?: Look internally

The short answer is yes.

The long answer is phpMyAdmin gives us a chance to see if we need to optimize our queries, and how badly we need to optimize them. I would imagine that you have seen this screen more than once if you have used phpMyAdmin:

It's the standard start screen for phpMyAdmin. Unless you are looking for ways to optimize, you might well go straight to your tables on the left hand menu, and never see the tab menu at the top. That menu, specifically the Status and Variables tabs are where we are going to start.

Let's start with the Status screen, which might be the most important tool that phpMyAdmin provides:

This is the top of the status screen. While it does have some interesting data, if you have never gone below the scroll you have missed out on some very important information. For the sake of brevity, I want to look at two very simple counter values which I obsess over, the first from my test environment:

The two values to pay very close attention to are, Handler_read_rnd and Handler_read_rnd_next. If those two values are in the red, then there are some queries out there that need to be checked, as when MySQL does a SELECT, it is reading the entire table. In some cases, this might be by design, as when you place an index on a table, it takes a bit longer to write, and it takes a bit more space. However, if you see something like this:

chances are, this wasn't by design. 141 Million requests to read a row on a fixed position, and 16 Billion requests to read the next row, probably means that we are missing an index or two (thousand). Obviously, this number grows based on the number of requests, so the more a search engine indexes your site, or the more visitors that you have, the greater a small missed index becomes. Full table scans are the enemy, and this gives you a quick way to spot how close that enemy is to the gates.

Another great table to check for query performance takes a look at selects and indexes directly:

This table pays particular attention to your joins. A dangerous combination is not using and index on either table, because your full table scans go up exponentially on the number of joins that you use. The more normalized your tables, the more you need to pay attention to your indexes, as well as the definition of the fields you are joining.

Finally, depending on a global variable, you also will want to check this variable table as well:

If you are logging your slow queries, this variable counter shows the number that have been identified for observation, depending on the setting of long query time. Those variables can be found from the variables tab. A quick look in my test environment shows this setting (for now):

These two tabs show quite a bit more information, some of which is absolutely vital for tuning your MySQL server. PhpMyAdmin makes it real easy for even the novice to spot a problem, and to have a basic understanding of what that problem might be. If a value is green, we are good. If it is red, it needs some attention. It also allows us to understand that we made some progress. When we restart our server, these session variables are all flushed. If we have made changes, we can see right off the bat if we made any impact.

EXPLAIN: Understanding the Gibberish

Now that we have identified that we need to do some optimization, let's look at some of the tools that we are going to use prior to finding our problems. The first of the tools, and probably the most helpful is to use EXPLAIN. EXPLAIN basically gives us our query execution plan. This tells us what MySQL plans to do with this query before it executes.

Without reading up on EXPLAIN, the output might not mean much to you. Using a table I created for a past tutorial, let's look at an unoptimized execution plan. My table only has two fields in this case, one being sales_id, and the other being sale_amount. Here's the query that I am working with:

1
2	SELECT sales_id,
3	sale_amount
4	FROM tutorial.sales
5	ORDER BY sale_amount

On the surface, this is a very simple query. Being a sales table though, the table will grow and grow and grow. I generated 200 records for the previous tutorial, and by doing a simple SELECT with an ORDER BY clause, it actually took quite a bit longer than I would have expected:

That query with only 200 records cost us .15 seconds. Let's use EXPLAIN to understand how MySQL see's this query. Just click the "Explain SQL" link to see the results:

Like most things, this doesn't make much sense unless you understand what is being said. To someone that has never run an EXPLAIN on a query, this might as well be written in hieroglyphics. Let's see if we can translate to something a little more understandable.

The select_type tells us that MySQL sees this SELECT as a simple, go to one table and process. If there was an union or a subquery, then this would show what part of the SELECT statement this would be calling. For instance if I create a query which has a subquery:

1
2	SELECT sale_amount as amount
3	FROM sales
4	WHERE sales_id IN (SELECT sales_id FROM sales_force WHERE sales_id = 4)

We get an EXPLAIN of this:

Which tells us about the query itself. In this case our select_type has changed to say that the first query is the primary, and then MySQL is going to go out and perform the subquery, which is a view, so there is another subquery to perform, hence we end with the three separate ids. The MySQL Reference manual gives all of the possible values:

Back to our original example:

The type is the one to pay attention to, as it tells you whether MySQL is going to scan the entire table, or whether it will be using an index to quickly find the results. This is the primary column to look at when you are optimizing your queries. From the order good to bad, the values are:

1. system, using the system tables to return one value
2. const, using primary key to return one row
3. eq_ref, query is joined on primary key or unique key
4. ref, query is joined on index and matches only a few rows
5. fulltext, joined on fulltext index
6. ref_or_null, does a ref, but also has to search for null rows
7. index_merge, join on the output row contains indexes
8. unique_subquery, indexed lookup function with unique values
9. index_subquery, same as last one, but not unique values
10. range, rows in a given range are retrieved using index to select the rows
11. index, bad, but at least using an index tree to scan
12. all, really bad, scanning the entire table

Where you want to start is getting optimizing any query that is either the type of index or all. If you can rid your application of these two types, your performance is going to improve. This my friends, is where you start.

The rest of the columns deal with the indexes that MySQL will use, and the number of rows that it will have to scan before it can see if there is a valid result. As you get rid of the "index" and "all" types, these come in handy to understand exactly what index MySQL is using to execute this query. To move a query up the ladder, you begin to tweak your indexes to improve performance. For the purpose of illustration, I am going to stick with ridding "all" or full table scans.

The final column is the "extra" column. The extra column tells you information about the query, whether or not a WHERE clause is used, whether or not it is an impossible WHERE, meaning this query will always return a NULL because the WHERE clause makes it impossible to execute. The one value that we need to pay very close attention to, and rid ourselves of, is the "Using filesort" which we have in our example. When you see that value, MySQL has to make another pass through the results to sort the values. So, in the case of our original query:

1
2	SELECT sales_id,
3	sale_amount
4	FROM tutorial.sales
5	ORDER BY sale_amount

Not only is MySQL scanning the entire table, but it has to scan it twice to sort the results because of our ORDER BY statement. This, is obviously doubly bad. We will optimize this query and many more in the following sections.

MySQL Profiler: After the query runs

In MySQL 5.0.37 another tool became available for us to use in optimization, and that is the MySQL profiler. In addition, phpMyAdmin added support for this feature in version 2.11, so if you have both of these versions available, we have another tool to add to optimization.

What the MySQL Profiler does, is give information about the bottlenecks of our queries. It allows us to see what happens during the actual execution of our queries, vice what EXPLAIN does, which is give the execution plan before. Let's see what information we can get from phpMyAdmin from my original bad query:

If we click on the "Profiling" checkbox below our query, a new world opens up with:

phpMyAdmin provides the actual execution times of the query that was provided. We can now see the bottlenecks of where our queries, or even table level structure should be addressed. Perhaps, we see the need from log files that this table really isn't written to as much as it is read from, so instead of InnoDB, we can now switch it to MyISAM.

There is a bit of a drawback to using phpMyAdmin when using the MySQL Profiler, and that is that the profiler is based on the session, and phpMyAdmin destroys the session on each pageview.. The problem this gives us is that we do not have a way to keep a running total of the profiling data, but there is a way to trick phpMyAdmin, albeit in a kludgy fashion:

1
2	SET profiling = 1;
3
4	SELECT sales_id,
5	sale_amount
6	FROM tutorial.sales
7	ORDER BY sale_amount;
8
9	SHOW profiles;

Which results in:

Since we are executing multiple queries, you do need to use the delimiter. This will show that my query is query_id 1. Each subsequent time I run this query, it is still query_id 1 since my session is being destroyed on start up. I am not sure if this is by design, a bug or ignorance on my part that phpMyAdmin destroys the session with the QUIT command, but we can work around this problem just a bit. MySQL has a wonderful write up on using the profiler by Robin Schumacher, and I am going to use a bit of Robin's query to get the number of operations in phpMyAdmin:

1
2	SET profiling = 1;
3
4	SELECT sales_id,
5	sale_amount
6	FROM tutorial.sales
7	ORDER BY sale_amount;
8
9	SELECT min(seq) as sequence,
10	state,
11	count(*) as operations,
12	round(sum(duration),5) as duration
13	FROM information_schema.profiling
14	WHERE query_id = 1
15	GROUP by state
16	ORDER by seq;

Again, not ideal with phpMyAdmin, but we still get what we want in the end:

Advertisement

Log Files and Global Vars: Catching the Queries

Before we put all that we have learned together, let's also take a look at how to capture queries by using MySQL's log files. We can capture every query that MySQL runs into the mysql.general_log table. By running this command:

1
2	SET GLOBAL general_log = 'ON';
3	SET GLOBAL log_output = 'TABLE';

We can now have a record for all of the queries that are run, regardless of the source. While this operation is expensive, and I would not run it on a production setting, it gives us a clear and concise method of getting all of our queries, and the order of their execution from our applications. In short, this might be the most valuable SQL query optimization tool you have in your toolbox. By setting these two GLOBAL vars, we have the final step to getting some practical optimization techniques.

Here's an abbreviated output from mysql.general_log table using this query:

1
2	SELECT event_time,
3	command_type,
4	argument
5	FROM mysql.general_log
6	ORDER BY event_time

produces this:

I basically have my query, along with everything that phpMyAdmin has been doing in the background. If I empty the table before each new command, I have something that I can work with on each page view, or AJAX call I make from my applications. To empty the log, we simply TRUNCATE the table like so:

1
2	TRUNCATE mysql.general_log

Truncate is a much better statement to use here than DELETE FROM, as the DELETE statement deletes row by row, where as TRUNCATE empties the entire table at once.

Once you are done with your optimization, you simply need to turn off your query log with this command:

1
2	SET GLOBAL general_log = 'OFF';

The general log becomes expensive over time, and certainly slows down the performance of your application. I keep it turned off in between my optimizations simply so I can get a organic feel for the performance of what I am writing. That said, in development, I always keep the slow query log turned on as I want to see my slower queries as a quick optimization tool. You can do this easily:

1
2	SET GLOBAL slow_query_log = 'ON';
3	SET GLOBAL log_queries_not_using_indexes = 'ON';
4	SET GLOBAL log_output = 'TABLE';

and we can check that from our Variables tab from our welcome page:

To see the output, we just need to either check the mysql.slow_log or we can use a query like this:

1
2	SELECT sql_text
3	FROM mysql.slow_log

Which gives me the actual queries that were logged as slow:

Putting it Together: We're talking about practice

Now we can put this altogether and use phpMyAdmin as a relatively decent query optimization tool. Let's start with the first query example:

1
2	EXPLAIN
3	SELECT sales_id,
4	sale_amount
5	FROM tutorial.sales
6	ORDER BY sale_amount

Which produces an output of:

We know we need to get at least one INDEX on this table. Let's stop and think how this table is used. It's a simple look-up table to join a sales_force table to tell us that they made a sale that was of the amount recorded. If all we ever do is join against this table on the sales_id, then that is what we need to index by clicking on the details link:

We can then just define that index like so:

Our original query still gives us a full scan, but in a practical application:

1
2	SELECT sfn.first_name,
3	sfn.last_name,
4	s.sale_amount
5
6	FROM sales_force_normalized sfn
7
8	INNER JOIN sales s
9	ON sfn.sales_id = s.sales_id

Let's see if this is any better:

Now we are getting somewhere. However, if we do something like this:

1
2	SELECT max(sale_amount)
3	FROM sales

Then we are back in the same boat of doing a full scan of the table. In this case, we can just edit the index and add the sale_amount:

Which improves us from really bad to just bad:

Or we can add a new index on just the amount:

And we have the wonderful result of:

Which means that MySQL doesn't even have to open the table, as it just has to look into the index. We have now hit the absolute optimum level for this COUNT function. Check out how long it took to execute this query now:

And for good measure, let's click the Profiling checkbox on the query to see any bottlenecks now:

Real World: It gets a bit harder

We have been playing with pretend queries, and pretend databases, but let's put this tutorial to the test. I have a stock WordPress install, with just the Lorem Ipsum plugin to add about 5000 posts and 11,000 comments, so we can put just a little strain on MySQL when we are making our selects.

Let's start logging our queries again from phpMyAdmin and also truncate the slow and general logs so we can see what happens when we load a page from WordPress:

1
2	SET GLOBAL general_log = 'ON';
3	TRUNCATE mysql.slow_log;
4	TRUNCATE mysql.general_log;

There is going to be a few artifacts in the general_log as phpMyAdmin causes some activity within MySQL, but we should be able to get everything in order when I reload my index page from WordPress at this point, and if we use a LIKE condition, we can get mostly just WordPress results since the tables are prefixed with wp_:

1
2	SELECT event_time,
3	command_type,
4	argument
5	FROM mysql.general_log
6	WHERE argument LIKE "%wp_%"
7	ORDER BY event_time

Which gives us a reasonable result of:

Now, we know that WordPress simply gives us 11 queries on loading the index page with a pretty vanilla installation. Let's find something to optimized that they might have missed. If we take the very first query that is executed whenever WordPress loads:

1
2	EXPLAIN SELECT option_name,
3	option_value
4	FROM wp_options
5	WHERE autoload = 'yes'

We find that this is not optimized:

Let's take a look at what they did through phpMyAdmin:

We see that there is an index on option_name, but there is not an index on autoload, which is the condition specifies on the index page. Let's add it, and see if we can't optimize the core WordPress installation just a bit:

Since, autoload is varchar and either "yes" or "no" from what I see, I can limit my index value to 1. Meaning, it now sees either "y" or "n" which reduces our time even greater. Let's see the EXPLAIN after we have optimized:

We have gone from really bad, to the fourth best type. Not bad for a couple of minutes of work. Granted, WordPress wasn't choking on this value, but depending on the load of your blog, every little bit helps. Granted now, the writes take longer, because we have to index our "y" or "n" for each line that is written.

If we go just a little further, we can also see the MySQL Profiler in action by just checking the "Profiling" checkbox. Now we see that our query is really buzzing right along:

Conclusion

Optimization isn't easy, nor is it really very much fun. However, when you ignore this step of development, it always comes back to haunt you. I believe that it is relatively easy to use the tools in phpMyAdmin to get a pretty good optimization look at your applications. That said, there are new tools added all the time, such as Jet Profiler which takes what I have just done into a real time, and graphical nature.

It's not difficult, or really time consuming to approach optimization through phpMyAdmin. It does take a little patience to learn how to do it, and what can be done. I hope that I have given you the tools to start being a bit more effective in your approaches. Please, let me know what you think in the comments section.

Jet Profiler for MySQL

Here is the link.

Ready to Buy Your New Car: Here’s What You Need to Bring to the Dealer!

byAdminJune 19, 2019 

The research process when it comes to looking for a new vehicle to purchase can be quite lengthy so when the day comes when you are finally ready to make the big purchase, it can be very exciting! Days, weeks, or even months have led you to this point and there is nothing you want more than to get the keys to your new ride and drive off. Of course, this can only be done so if you have all your paperwork and necessary requirements readily available. It’s important to understand what fees are associated with buying a car and what you need to bring with you to the dealer to ensure you can drive away the same day.

Preparing what you need ahead of time can help ensure you don’t miss anything come the day of purchase. There are a few very essential items/documents you need to bring with you in order to complete your vehicle purchase.

 

Driver’s license: This may seem like a given, but you would be surprised how many people forget it. When purchasing a new vehicle, many people find alternative ways to get to the dealership; Uber, public transportation, ride-sharing, etc. Because of this, some forget to bring their license with them. Your driver’s license is important for confirming and verifying your identity when purchasing your vehicle. If you plan on driving your car off the lot, the dealership will not allow you to do so without a proper license on you. If you forget it and plan on driving your new ride home, you will either have to arrange for another day, arrange for vehicle delivery, or get someone to come pick it up for you.

Proof of Insurance: Just like a driver’s license, you cannot legally operate a vehicle without insurance in Canada. Dealers need to see proof that you have taken out a policy on the new vehicle before allowing you to drive it off of the lot. If you have recently purchased a policy and don’t have the slip yet, providing a printed copy will suffice. Without proof of insurance, you will not be allowed to drive your new car off the lot.

Employment/Credit Information: Typically, dealers will run a credit report for you, however, it’s good to have a report handy with you as well as your credit card. Some dealers may require employment information if they need to verify you can, in fact, pay for the vehicle. If any issues arise with your credit information or you don’t have the required back up information, this may delay the entire car buying process.

Form of payment: Whether you are purchasing your vehicle outright, leasing, or financing, you need to bring some form of payment. If you are purchasing outright, you need to present either a cheque, bank card or credit card that will cover the entire cost. When it comes to financing/leasing, payment is required for your down payment. If you are not putting a down payment down, it is still vital to bring your payment method. This is so the dealer can register the monthly payments to either your bank or credit card. Without this, they will not be able to bill you for your payments monthly, ergo, they will not let you drive off the lot until they are 100% they have a method of taking payments from you.

Dealer Invoice Report: Our Dealer Invoice Report can save you thousands on your new vehicle purchase and many dealers gladly accept the report. Ensure you have it printed out or have a digital copy readily available to show to the dealer. The report can help you knock off some serious dollars on your whole purchase or finance/lease payments. If you do forget it, you could be foregoing a plethora of savings.

 

What fees are associated with buying a new car?

There are a few required fees you must pay before completing your vehicle purchase. It’s imperative that you are aware of these fees so you are not hit with any surprises at the dealership.

 

New plate costs: A front and back plate are legally required when operating a vehicle. These need to be paid for prior to purchasing your vehicle so the dealership can ensure your vehicle is legally fit for the road. If you have a previous vehicle and you want to take the plates off and transfer to your new vehicle, you can do so and the dealer will waive this fee. If you want entirely new plates, however, you will have to purchase them at an extra cost of $60-120 depending on your place of residence (prices will differ for personalized plates and commercial vehicles).

Delivery fees: If you plan on having your vehicle delivered to you, it may cost you a little extra. Depending on the distance from the dealership to your home, the dealership may charge you a delivery fee. You can, however, find dealers who waive this fee for you.

Loan payment fees: When financing or leasing a vehicle, you are given an exact amount that will be billed to your credit card/bank weekly, bi-weekly, or monthly. It’s important to keep an eye out on these payments and ensure they match up to what original cost was given to you. If you see the payments that are coming out are slightly higher than initially agreed upon, it may be due to loan payment fees. Some automakers will add this fee on to car buyers monthly payments, usually around $10-$20 extra per month. It’s important to fully read your payment terms and conditions so you are not hit with any unwanted surprises when your payments come out. Not all automakers/dealers will charge a loan payment fee, so it’s essential to research which ones will waive it.

 

Making sure you have all the necessary documents and paperwork ready with you on the day of your purchase can help the process run smoothly and will allow you to drive off with your vehicle the same day. Doing so will also prepare you so you don’t run into any unwanted surprises.

Credo | 光通信DSP领域

 Here is the article. 

一次发布5款芯片，Credo入局光通信DSP领域

作者：

李杭森

1.6w

来源：爱集微

#默升科技#

2020-09-14

集微网消息，9月8日，Credo在深圳举办了媒体交流会，宣布推出一款专供于5G无线通信网络中前传/中传光模块的高性能光通信数字信号处理器（DSP）Seagull 50芯片，以及推出新一代Dove系列低功耗PAM4高速光通信数字信号处理器（DSP）。

会上，公司首席运营官特别助理、资本市场部总经理陈冉介绍了Credo的成长史并指出，我们现有的技术都是由中国研发中心完成，Credo的成长史充分地说明我们不是一家美国公司，是一家成长于中国，服务于全球的国际化公司。

Credo的三个阶段

据陈冉介绍，Credo成立于2008年，是由三名海归华人创始人靠着自己的信念在上海张江创建，从此为中国培养了一批从事全世界最高速率SerDes的研发团队。

与初创时期，依靠融资维持经营发展的企业不同，在2008年至2014年期间，Credo仅依靠创始人的自有资金以及强大的信念，踏踏实实地研发SerDes高速芯片，这是Credo的1.0阶段，也给今天的Credo带来了宝贵的经营理念，就是我们的发展不能单纯依赖投资，我们必须靠自身的商业经营获得持续发展。

2015年，Credo建立了专注于先进通信物理层技术和芯片产品研发的默升科技，进入2.0阶段。在集团CEO Bill Brennan的带领下，将公司先进的技术和卓越性能的芯片产品逐渐转化为实实在在的订单。在SerDes IP领域，Credo拥有全球最大最全的SerDes IP，而且拥有全球最广的SerDes IP客户群，进入了全世界最顶级的数据中心、云计算、大数据、5G、人工智能、自动驾驶等应用领域。

随着中国市场的快速增长，Credo 进入了3.0阶段，2018年Credo在中国建立了以客户应用支持、生态建设和销售服务为主的芯境科技，支持中国芯片产业快速发展。

当外部环境变化时，Credo也克服重重困难，利用公司现有的全球布局，打破束缚，更好地为全世界最优秀的企业服务。2019年和2020年，我们积极引入中国投资人，陆续完成了C轮和D轮融资，为公司未来3-5年的发展提供了充沛的资金，使公司股权结构更多元化；2020年Credo上海正式迁入了新的办公楼，依靠自有资金建立了符合国际标准的现代化实验室；我们设立了武汉分公司，我们即将设立南京分公司；与此同时中国团队的建设也迎来了一波新高潮，我们组建了针对中国客户的独立自主的团队，从研发到销售，从运营到技术支持，我们求贤若渴，未来的一年大中华区的员工数量预计将同比增长50%。从信念到执行，芯无界，境自高。

陈冉表示，在公司管理团队及前期积累的技术和客户群的基础上，经过5年的研发和打磨，Credo 28nm线卡芯片出货量已经超过200万颗。虽然Credo拥有业界全工艺节点的Serdes IP和广泛优质的客户基础，但是公司经营方针已经从早期的IP业务为主转为芯片、AEC等多元化产品线的长期可持续化发展策略。。

Seagull 50：专供于5G无线通信网络中前传/中传光模块

据Credo销售副总裁杨学贤介绍，5G将需要更大的传输容量和更快的传输速率支持，光器件模块需要进行相应升级从而带来海量光器件需求。同时，提高设备性能、降低5G设备成本及功耗是业界面临的重大挑战。

Credo Seagull 50芯片是一款专供于5G无线通信网络中前传/中传光模块的高性能光通信数字信号处理器（DSP）。Credo Seagull 50 满足了移动网络不断攀升的带宽需求，支持长距离传输及工业级工作温度范围。Credo Seagull 50 可配置为两种工作模式：2x25G<—>1x50G及1x50G<—>1x50G。Seagull 50产品采用Credo独特设计架构，最大程度减小芯片尺寸，并使用主流工艺制程以降低产品成本。此外，Seagull 50芯片，具备业界领先功耗，可实现SFP56模块1.5W的功耗目标，可实现QSFP28模块2W的功耗目标，可持续降低运营成本。

Credo架构副总裁钱浩立表示：“Credo Seagull 50 高性能DSP是5G无线通信网络的理想之选，该产品是Credo专为5G下一代前传和中传网络而打造。”

650Group创始人兼技术分析师ChrisDePuy表示：“在5G网络中，无线接入网（RAN）架构有了很大改变，这使得5G网络需要更多高带宽的前传和中传连接。5G时代大量的新增网络连接，需要能够以50G速率传输数公里的新一代大容量传输系统作为支撑。”

Credo Seagull 50 是一款多功能全双工产品，具有行业领先的低功耗性能，可用于下一代支持基于PAM4调制的50GbpsSR/DR/FR/LR/ER多种传输距离下的QSFP28，DSFP及SFP56可插拔光模块。

Seagull 50可在-40℃至+85℃的工业级温度范围内工作，非常适合在数据中心和5G无线/eCPRI前传、中传和回传应用中使用。Seagull 50是一款具有两种模式的光通信DSP，可用作Gearbox或Retimer。在Gearbox模式下，芯片配置为：设备侧双通道24.33-25.78GbpsNRZ到线路侧单通道50.135-53.125Gbps PAM4；在Retimer模式下，配置为：单通道50.135-53.125Gbps PAM4到单通道50.135-53.125Gbps PAM4。

Seagull 50采用了Credo领先的数字信号处理（DSP）技术和均衡技术。在保持高性能的同时，低成本是需要广泛部署的5G网络对光模块的主要诉求之一，因此作为光模块中关键组件的DSP需要实现成本相宜，进而推动DML激光器的广泛使用，最终可以加速那些还未成熟的光器件的发展。这种设计导向还要支持作为前传刚需的工业级工作温度范围，以及中传/回传中更长的传输距离。DSP可以通过补偿由光器件、温变和光纤原因造成的光损伤及非线性效应来提供高性能、稳定可靠的光通信解决方案。

Credo Seagull 50 关键特性包括：

-2x25G<—>1x50G及1x50<—>1x50G两种配置模式

-可与现有光模块实现互联互通

-发端多阶预加重

-连续时间线性均衡器（CTLE）

-高性能DSP具有多阶DFE/FFE接收均衡能力

-经过优化的、领先同侪的紧凑固件

-支持工业级温度范围（-40oCto85oC）

-确定的时延  行业领先的超低功耗

Dove系列光通信DSP：专为下一代数据中心网络平台打造

在低功耗PAM4高速光通信数字信号处理器（DSP）方面，Credo此次发布的Dove系列包括四款新品：Dove100、Dove150、Dove200及Dove400光通信DSP，专为下一代100G/200G/400G数据中心网络平台打造。

Credo独特的PAM4DSP架构可最大程度减小芯片尺寸，产品使用主流工艺制成，可为下一代光模块提供最佳的性能、成本与功耗：使用CredoDove系列PAM4高速光通信DSP来设计的可插拔光模块，只需较低的成本便可拥有行业领先的性能及超低功耗。

Credo销售副总裁杨学贤表示，电力成本是IDC运营成本中占比最高的部分，大约占公司运维成本的60%，此外，光模块功耗过高还会增加数据中心的制冷成本，因此无论是5G基站，还是数据中心，都需要用到低功耗光电芯片，从而持续降低运营成本。Credo推出的新一代Dove系列低功耗PAM4高速光通信数字信号处理器（DSP），可以满足用户对光模块低功耗的需求。

Credo架构副总裁钱浩立表示：“云平台的运营商们亟需能够在扩展带宽同时又保持低功耗与低成本的解决方案。Credo很荣幸能在解决这一问题上做出贡献，使得光模块能够满足下一代数据中心带宽扩展的需求。”

650Group的创始人兼技术分析师AlanWeckel表示：”100/200/400G现已占数据中心网络连接市场50％以上的份额，并将在未来保持持续增长的态势，成为数据中心主流速率。云平台的运营商正在部署更高密度的100G网络拓扑结构，并已经开始为部署200G和400G网络而投资，以适应不断增长的网络带宽需求。随着网络速率的不断提升，网络的功耗密度和可扩展性已成为光模块及交换机设计中必不可少的标准之一。”

Credo的数字信号处理（DSP）技术和均衡技术可在保持芯片低功耗的同时很好地补偿光损耗。所有CredoDove系列产品全部具有Credo数字信号处理技术的关键特性，包括：

-高性能DSP

-连续CTLE及DFE/FFE接收均衡

-发端多阶预加重

-行业领先的超低功耗

-完整的测试与诊断功能

-与IEEE行业标准互联互通

-经过优化的、领先同侪的紧凑固件

此外，Dove200和Dove400产品的每条信道（lane）都配有独立锁相环（PLL），支持分接（breakout）配置。

Dove100用于下一代高性能100GbpsDR/FR/LRQSFP28光模块。可将设备侧接收的四通道25.78125GbpsNRZ信号，聚合为单通道106.25Gbps PAM4传送至光侧。

Dove150用于低功耗、高性能的100GbpsDR/FR/LRQSFP-56光模块。可将设备侧接收的二通道53.125GbpsPAM-4信号，聚合为以单道106.25Gbps PAM4信号传送至光侧。

Dove200无需配备Gearbox或FEC转换即可实现无缝互连架构，帮助数据中心使用具有50GPAM4连接的交换机进行扩展。支持IEEE802.3200GBASE-SR4/DR4/FR4/LR4及400GBASE-SR8规范。起中继功能，将设备侧接收的四通道53.125Gbps PAM4信号以四通道53.125Gbps PAM4信号传送至光侧。

Dove400用于低功耗、高性能的400GbpsDR4/FR4/LR4OSFP和QSFP-DD光模块。可将设备侧接收的八通道53.125GbpsPAM-4信号，以四通道106.25Gbps PAM4信号传送至光侧。（校对/Candy）

Credo

 Credo introduces the HiWire™ LP CLOS #AEC, a 400G PAM4 copper #interconnect for in-rack CLOS applications. With low power DSPs and reach up to 3M, the LP CLOS AECs are up to 75% more power-efficient than #AOCs and have 75% less bulk than #DACs. https://lnkd.in/g3Gzmau